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Abstract 


A  local  computer  for  the  Air  Force  Institute  of 
Technology  Digital  Engineering  Laboratory  was  designed  and 
the  network,  command  language  interpreter  modules  were 
implemented.  The  requirements  for  this  network  were 
specified  by  interviewing  nine  faculty  members  associated 
with  the  Digital  Engineering  Laboratory  and  then  translating 
their  functional  requirements  into  a  detailed  set  of 
hardware  and  software  system  requirements.  Structured 
Analysis  was  used  to  produce  a  structured  specification  for 
the  applications,  host- to-host,  network,  and  link  protocol 
requirements.  Yourdon  and  Constantine's  Transform  Analysis 
and  Transaction  Analysis  techniques  were  then  used  to 
develop  a  set  of  module  structure  charts  for  the  software 
design.  The  network  uses  a  loop  topology  for  the  nodes  with 
a  star  of  up  to  four  hosts  connected  to  each  node.  The 
nodes  are  implemented  using  a  Universal  Network  Interface 
Device  (UNID)  developed  at  the  Air  Force  Institute  of 
Technology.  Initially,  the  network  will  include  an  Intel 
Series  II  Microcomputer  Development  Station,  a  Digital 
Equipment  Corporation  VAX-11/780,  and  a  Data  General  Nova. 
These  computers  will  be  connected  to  the  nodes  using  twisted 
pair  and  the  two  UNIDs  in  the  initial  configuration  will  be 
interconnected  with  a  duplex  fiber  optic  link  supporting 
transmission  rates  up  to  56  Kbs  .  The  X.25  protocol  was 
selected  to  implement  a  host-to-host  transfer  mechanism  in 
conjunction  with  a  basic  routing  algorithm  using  a  lookup 


table  stored  in  each  UNID.  The  network  command  language 
interpreter  allows  file  transfer  commands,  session  control 
commands,  and  user  help  requests  to  be  parsed  and  the 
appropriate  parameters  passed  to  lower-level  modules. 
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I.  Tntioduction 


The  purpose  of  this  investigation  was  to  design  a  local 
computer  network  for  the  Air  Force  Institute  of  Technology 
School  of  Engineering  Digital  Engineering  Laboratory.  This 
network,  named  the  Digital  Engineering  Laboratory  Network 
(DELNET) ,  was  first  proposed  in  1978  when  the  number  of  host 
computers  in  the  Digital  Engineering  Laboratory  had  grown  to 
six  and  there  were  insufficient  peripheral  devices  to  allow 
the  computers  to  be  used  to  their  full  capacity.  Local 
networks  at  this  time  were  becoming  increasingly  commonplace 
in  universities  and  corporations.  This  was  due  to  their 
desire  to  increase  their  information  processing  power 
without  adding  additional  computers.  Also,  universities 
wishing  to  perform  research  in  the  area  of  local  computer 
networking  were  developing  their  own  networks  so  that  they 
could  have  the  flexibility  to  change  network  characteristics 
and  evaluate  different  network  topologies,  protocols,  and 
transmission  mediums.  Interest  in  both  of  these  potential 
activities  provided  the  impetus  for  the  development  of  a 
local  computer  network  at  the  Air  Force  Institute  of 
Technology. 

Historical  Perspective 

It  is  only  in  the  last  decade  that  computer  networks 
have  become  commonplace.  The  development  of  the  Defense 
Advanced  Research  Projects  Agency  Network  (ARPANET)  probably 
did  more  to  stimulate  the  development  of  computer  networks 
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than  any  other  factor.  This  packet-switching  network  has 
been  highly  successful  and  today  continues  to  be  the  primary 
computer  network  in  the  United  States  and  ties  together  the 
most  powerful  research  computers  in  the  country  (Ref.  12: 
5-23)  . 

It  was  not  until  the  advent  of  the  microprocessor, 
however,  that  local  networks  tailored  to  a  particular 
organization  and  interconnecting  minicomputers  became 
practical.  The  microprocessor  made  local  networks  more 
practical  because  it  allowed  economic  network  nodes  to  be 
developed.  These  were  cost-effective  and  yet  offloaded  much 
of  the  network  protocol  processing  overhead  from  the 
computer  hosts  on  the  network.  Also,  the  microprocessor 
decreased  the  cost  of  computers  and  increased  the  number  in 
use.  This  made  it  practical  for  organizations  to  implement 
a  local  network  of  microcomputers  in  lieu  of  time-sharing 
off  a  mainframe  computer. 

Another  significant  development  has  been  the  emergence 
of  various  link  and  network  protocols.  These  protocols  have 
started  to  be  standardized,  but  because  protocol  design  is 
still  it,  its  infancy,  there  is  no  recognized  "best"  protocol 
for  a  given  application  (Ref.  20:  156).  IBM  has  played  a 
leading  role  in  protocol  development  first  by  introducing 
the  binary  synchronous  (BSC)  protocol  and  later  by 
introducing  the  Systems  Network  Architecture  (SNA)  which 
includes  the  synchronous  data  link  control  (SDLC)  protocol. 
SDLC  was  one  of  the  first  bit-oriented  protocols;  a  set  of 
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protocols  which  has  emerged  as  the  most  efficient  and 
flexible  for  managing  the  link  between  two  computers.  The 
X.25  protocol,  which  defines  the  interface  of  a  computer  to 
a  pac ke t - sw i tch  i  ng  network,  has  just  recently  become  a 
standard  and  could  be  the  initial  protocol  for  interfacing 
computers  in  the  next  decade  (Ref.  3:  11). 

A  great  deal  of  research  has  been  conducted  to  design 
efficient  routing  algorithms  which  direct  the  flow  of  the 
packets  through  the  switching  nodes  in  a  network.  Although 
a  number  of  efficient  algorithms  have  been  developed,  this 
area  of  research  is  also  still  in  its  early  stages  (Ref. 
16:  42-97)  . 

Until  very  recently,  most  local  computer  networks 
available  commercially  were  developed  by  a  computer  firm  to 
interface  that  manufacturer's  systems.  The  only  way  of 
interfacing  other  computers  to  that  network  was  to  develop 
an  emulator.  This  emulator  would  make  that  computer  appear 
at  the  interface  as  one  of  the  manufacturer's  computers  to 
the  network.  IBM's  SNA  and  the  Digital  Equipment 
Corporation  Network  (DECNET)  are  both  examples  of  this  type 
of  network  (Refs.  3:  11;  7)  .  In  the  last  two  years,  two 
new  local  networks  have  become  commercially  available  that 
can  interface  a  heterogeneous  set  of  computers.  Xerox  has 
introduced  ETHERNET  and  Ungermann-Bass  has  developed  NET/ONE 
(Refs.  5,14)  .  Because  of  the  state  of  the  art  techniques 
used  in  these  networks,  they  are  worth  studying  in  more 
detail . 
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NET/ONE  uses  a  network  interface  unit  (NIU) ,  which  may 
contain  up  to  four  Z-80A  microprocessors  and  64  Kbytes  of 
memory,  to  interface  up  to  sixteen  devices  to  the  network. 
These  devices  may  include  host  computers  or  peripheral 
devices  and  are  interfaced  to  the  NIU  using  the  RS-232 
protocol.  NET/ONE  uses  a  bus  architecture  and  interfaces 
the  NIUs  to  the  bus  through  a  transceiver  interface 
contained  in  each  NIU.  The  bus  is  a  baseband  coaxial  cable 
supporting  transmission  speeds  of  up  to  4  Mbs.  Because  the 
NIU  is  connected  to  this  cable  through  a  passive  tap,  a 
failure  of  an  NIU  only  affects  those  hosts  and  devices  on 
it.  The  bus  access  mechanism  uses  a  contention  channel 
protocol  where  each  NIU  can  transmit  whenever  it  senses  that 
the  bus  is  idle.  If  it  receives  another  NIU's  transmission 
while  transmitting  data  itself,  then  a  collision  has 
occurred  and  the  packet  is  retransmitted  a  set  delay  after 
the  NIU  again  senses  that  the  bus  is  idle  (Ref.  5). 

ETHERNET  is  very  similar  to  a  NET/ONE  without  the 
NIUs.  Instead  each  host  must  interface  to  a  coaxial  cable 
through  its  own  transceiver  interface  and  handle  the 
contention  channel  protocol  itself  (Ref.  14). 

Thus  computer  networks  have  evolved  from  a  few 
geographically  distributed  networks  interconnecting  large 
mainframe  computers  such  as  ARPANET  to  also  include  high 
speed  local  networks  such  as  NET/ONE  and  ETHERNET.  These 
two  local  networks  make  the  interconnection  of  a 
heterogeneous  set  of  minicomputers  and  microcomputers 
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practical.  The  standard  protocols  and  routing  algorithms 
developed  to  date  are  the  principal  resources  from  which  the 
design  of  DELNET  could  be  derived.  Existing  local  networks 
such  as  ETHERNET  and  NET/ONE  also  provide  a  basis  for 
comparison  with  the  DELNET  design.  So,  it  is  from  this 
perspective  that  the  development  of  DELNET  has  taken  place. 
The  following  section  gives  some  background  on  the  previous 
development  efforts  which  preceded  this  particular 
investigation. 

Background 

This  effort  follows  two  other  graduate  research 
projects  addressing  the  development  of  a  local  computer 
network  for  the  Digital  Engineering  Laboratory.  R.  Cade 
Adams  and  Donald  Ravenscroft  conducted  concurrent 
investigations  although  with  different  emphases  (Refs. 
1,16)  . 

Adams'  investigation  resulted  in  several  general 
theoretical  concepts  upon  which  that  he  felt  that  the  design 
of  DELNET  should  be  based.  However,  the  conceptual  design 
was  based  upon  only  a  cursory  analysis  of  the  actual  Digital 
Engineering  Laboratory  requirements  and  more  upon 
requirements  of  local  networks  in  general  (Ref.  1). 

Ravenscroft ' s  investigation  was  much  more  productive 
and  resulted  in  the  design  of  a  routing  algorithm  for 
DELNET.  Also,  some  recommendations  were  made  for  the  choice 
of  a  link  protocol  (Ref.  16).  However,  neither  of  these 
investigations  approached  the  problem  from  the  users' 
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viewpoint  and  much  work  remained  to  develop  a  design  for 
DELNET  that  could  be  implemented  in  the  Digital  Engineering 
Laboratory . 

Objective  ol  This  Investigation 

The  objective  of  this  investigation  was  to  specify  the 
design  of  DELNET  in  sufficient  detail  that  subsequent 
investigations  could  concentrate  on  actually  implementing 
the  design.  The  design  had  to  be  based  upon  the  actual 
requirements  of  the  Digital  Engineering  Laboratory  and  their 
projected  uses  of  DELNET.  This  was  imperative  because 
unlike  ETHERNET  or  NET/ONE  that  were  designed  for  high 
throughput  and  automated  data  processing,  one  of  the  chief 
uses  of  DELNET  will  be  as  a  teaching  and  research  tool. 
Thus,  flexibility  in  changing  the  protocols  and  topology  of 
the  network  were  important  for  DELNET  and  these  requirements 
could  not  be  met  by  NET/ONE  or  ETHERNET  because  of  their 
dependence  on  the  bus  architecture  and  the  contention 
channel  protocol. 

Approach 

The  development  of  computer  networks  has  not  reached  a 
stage  where  there  is  a  set  development  approach  to  be 
followed.  However,  there  are  standard  procedures  for  the 
engineering  development  of  any  system  and  it  is  from  these 
procedures  that  an  approach  was  formulated. 

First,  a  top-down  development  of  the  design  was 
chosen.  This  approach  allowed  the  design  to  first  address 
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those  levels  closest  to  the  user  and  thereby  insure  that  the 
design  was  consistent  with  the  user's  requirements.  Then 
lower  levels  of  the  design  were  developed  to  support  the 
requirements  of  the  next  higher  level.  Care  was  taken, 
however,  to  insure  that  each  level  had  sharply  defined 
interfaces  with  the  levels  above  and  below  it  so  that  a 
level  designed  with  one  protocol  could  be  replaced  easily 
with  another  protocol  when  desired. 

Due  to  the  size  of  the  development  effort,  an  approach 
using  structured  analysis  and  design  techniques  was 
considered  imperative.  These  techniques  result  in  clear 
written  specifications  and  diagrams  that  provide  to  those 
implementing  the  design  the  unambiguous  information  they 
need. 

The  first  phase  of  the  investigation  consisted 
primarily  of  researching  the  literature  and  qaining  a 
working  knowledge  of  computer  networks,  protocols,  hardware 
interface  devices,  and  the  capabilities  of  the  computers  in 
the  Digital  Engineering  Laboratory.  Existing  local  computer 
network  architectures  were  studied  in  particular  as  were  the 
newer  bit-oriented  protocols  being  used  increasingly  in 
local  computer  networks. 

Once  a  sufficient  background  had  been  gained,  a  user 
interview  outline  was  designed  and  faculty  members 
associated  with  the  Digital  Engineering  Laboratory  were 
interviewed.  From  these  interviews,  a  set  of  projected  uses 
and  functional  requirements  were  compiled  and  these  were 
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used  to  derive  the  system  requirements. 

The  system  requirements  consisted  of  both  hardware 
requirements  for  the  topology,  hosts,  nodes,  and 
transmission  mediums,  as  well  as  software  requirements.  The 
software  requirements  were  documented  using  Structured 
Analysis  (Ref.  6).  The  structured  specification  consisted 
of  a  set  of  data  flow  diagrams  and  a  data  dictionary. 

The  system  requirements  were  then  used  to  develop  a 
hardware  design  and  a  software  design  of  the  high-level 
protocols.  These  protocols  were  then  partially  implemented 
on  the  VAX-11/7  80  and  user  feedback  on  the  performance  was 
obtained.  The  final  stage  of  the  investigation  resulted  in 


the  design  of  the  lower-level  protocols. 


Overview  ol  Thesis 

The  structure  of  the  thesis  basically  follows  the 
approach  that  was  taken  in  the  investigation.  The  DELNET 
functional  requirements  are  analyzed  in  Chapter  II. 
Appendix  A  provides  supporting  information  including  the 
compilation  of  the  results  of  the  user  interviews  and  a  list 
of  those  interviewed  and  their  specific  areas  of  interest 
with  respect  to  the  Digital  Engineering  Laboratory. 

Chapter  III  translates  the  functional  requirements  into 
hardware  and  software  requirements.  Structured  Analysis  is 
described  and  data  flow  diagrams  are  used  throughout  the 
chapter  to  support  the  written  description  of  the  software 
requirements.  Supporting  the  hardware  requirements  is 


Appendix  B  which  contains  a  floor  layout  of  the  location  of 


the  principal  computers  in  the  Digital  Engineering 
Laboratory.  Appendix  C  contains  the  complete  structured 
specification  in  support  of  the  software  requirements. 

The  design  phases  of  DELNET  are  described  in  Chapter 
IV.  The  design  of  the  hardware  is  specified  including  the 
topology  to  be  employed  initially,  the  first  hosts  to  be 
included  in  the  network,  the  node  to  be  used  in  the  network, 
and  the  transmission  mediums  to  be  used.  The  software 
design  is  described  in  three  stages.  First,  the  design 
techniques  that  were  used  are  summarized  and  module 
structure  charts  from  the  DELNET  design  are  used  to 
illustrate  their  application.  Then,  the  allocation  of  the 
software  modules  to  the  host  and  node  processors  is 
specified.  The  actual  software  design  consists  of  a  set  of 
module  structure  charts  which  are  in  Appendix  D. 

Chapter  V  describes  the  implementation  and  testing  of 
the  network  command  language  interpreter.  In  this  chapter, 
the  factors  affecting  implementation  are  described  as  well 
as  the  testing  techniques  employed.  The  source  code  for  the 
implemented  modules  is  in  Appendix  E  while  Appendix  F 
contains  the  testing  documentaion.  Appendix  G  contains  the 
user  manual  for  DELNET. 

Finally,  Chapter  VI  summarizes  this  investigation  and 
gives  recommendations  for  follow-on  research  efforts. 
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11.  DELNET 


Introduction 

This  chapter  specifies  the  functional  requirements  of 
DELNET.  First,  the  background  of  the  requirements  analysis 
is  discussed,  in  the  next  section,  the  content  of  the  user 
survey  that  was  used  to  help  determine  the  DELNET 
requirements  is  described.  Also  included  in  this  section  is 
a  description  of  how  the  survey  was  conducted.  The  next 
section  summarizes  the  results  of  the  survey  by  describing 
the  projected  uses  of  DELNET  as  well  as  the  users' 
perception  of  several  functional  requirements.  Finally, 
other  functional  requirements  as  well  as  constraints  not 
addressed  by  the  user  survey  are  discussed. 


Possibly  the  most  crucial  step  in  developing  a  computer 
network  is  the  specification  of  the  network  requirements. 
Yet,  this  phase  of  development  was  treated  inadequately  by 
both  individuals  whose  work  this  research  project  was 
continuing  (Refs.  1,16).  While  Adam's  thesis  discusses 
user  requirements,  it  only  lists  characteristics  generally 
desired  of  local  networks  and  does  not  justify  these 
characteristics  as  being  applicable  to  DELNET.  Also,  there 
is  no  reason  to  believe  that  this  list  of  requirements  is 
complete  (Ref.  1).  In  Ravenscrof t ' s  thesis,  some  attention 
is  given  to  the  pedagogical  requirement  for  DELNET  as  well 
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as  many  of  those  requirements  addressed  by  Adams,  but 
Rave nsc r  of  t  '  s  requirements  analysis  is  also  incomplete 
(Ref.  16:  43).  Thus,  many  of  the  design  decisions  that 
follow  in  both  theses  are  only  based  upon  what  is  generally 
desired  in  networks. 

While  it  is  possible  to  specify  many  requirements  that 
are  generally  desired  in  a  network,  using  this  approach 
alone  will  result  in  an  incomplete  and  inaccurate 
requirements  speci f ication  for  several  reasons.  First, 
local  networks  differ  greatly  in  their  requirements  because 
they  usually  serve  only  one  organization  (Ref.  21:  131). 
Thus,  the  requirements  for  local  networks  are  usually  as 
varied  as  the  organizations  themselves.  Second,  not  all 
requirements  for  a  network  may  have  the  same  importance  and 
the  resources  available  (such  as  time  or  money)  may  not  be 
adequate  to  satisfy  all  requirements.  Since,  the  relative 
importance  of  the  requirements  also  varies  widely  with  each 
local  network,  it  is  almost  impossible  to  obtain  a  weighting 
of  requirements  by  strictly  considering  some  "ideal  network" 


for 

all  cases. 

Finally, 

there 

may  be  unique 

requirements 

for 

the  network 

and  these 

will 

be  overlooked 

i f  only  the 

requirements  for  the  "ideal  network"  are  considered.  These 
pitfalls  were  demonstrated  when  the  two  previous  research 
efforts,  which  were  concurrent  efforts,  resulted  in 
conflicting  designs.  Ravenscroft  did  not  consider  the 
topology  recommended  by  Adams  because  of  its  inflexibility, 
while  Adams  rejected  the  topology  recommended  by  Ravenscroft 


because  of  its  complexity 


User  Survey 

A  systematic  approach  was  needed  to  specify  the 
requirements  for  DELNET  that  would  tailor  it  to  the 
requirements  of  the  Digital  Engineering  Laboratory.  Thus,  a 
three-part  user  survey  was  designed. 

In  the  first  section,  the  users  were  asked  what 
applications  could  be  served  by  DELNET  from  their 
utilization  perspectives.  To  aid  the  users  being 
interviewed,  nine  common  local  network  applications  were 
listed  which  the  user  could  evaluate  on  a  five-point  scale 
from  "of  no  use"  to  "very  beneficial."  These  applications 
included  peripheral  sharing  among  the  computers  in  the 
network,  file  accessing  and  transfers  across  the  network, 
sharing  software  tools  on  the  network,  accessing  the 
Advanced  Research  Projects  Agency  Network  (ARPANET), 
accessing  the  CYBER  750  host  installation  computer, 
accessing  the  Air  Force  Institute  of  Technology  Network 
(AFITNET)  once  it  is  implemented,  doing  distributed 
processing,  managing  distributed  databases,  and  providing 
fault  tolerance.  Finally,  the  section  asked  the  users  to 
identify  the  applications  that  they  felt  should  be 
implemented  first. 

The  second  section  asked  the  user  to  estimate  the 
requirements  from  their  perspectives  for  nine  basic  network 
parameters.  These  were  divided  into  five  user-oriented 
parameters  and  four  design-oriented  parameters.  The 
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user-oriented  parameters  were  throughput,  response  time,  the 
user  interface,  security,  and  availability  of  the  network. 
Each  of  the  subsections  addressing  a  parameter  had  a  number 
of  questions  to  aid  the  user  in  evaluating  the  requirement 
for  that  parameter.  Each  user  was  asked  to  identify  any 
other  user-oriented  parameters  that  might  influence  DELNET's 
design.  The  design-oriented  parameters  were  flexibility, 
performance  monitoring,  special  pedagogical  requirements, 
and  the  availability  of  a  distributed  processing  language. 
As  with  the  user-oriented  parameters,  each  subsection  had  a 
number  of  questions  to  help  the  user  evaluate  the 
parameter.  The  user  was  also  asked  to  identify  other 
design-oriented  parameters.  Finally,  the  second  section 
concluded  by  having  the  user  rate  each  of  the  nine 
parameters  on  a  five-point  scale  from  "not  applicable"  to 
"essential."  This  was  included  to  help  evaluate  the  relative 
importance  of  the  network  parameters. 

The  third  section  asked  the  users  to  make  any  other 
comments  that  they  felt  might  help  specify  the  requirements 
of  DELNET. 

The  identification  of  the  users  of  DELNET  was  also  an 
important  part  of  the  requirements  analysis.  Although 
undergraduate  and  graduate  students  will  use  DELNET,  their 
use  of  DELNET  would  be  primarily  at  the  direction  of  the 
Electrical  Engineering  (EE)  Department  and  the  Mathematics 
Department.  Thus,  the  students  had  little  interest  or 
insight  into  the  projected  uses  of  DELNET.  On  the  other 
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hand,  many  faculty  members  had  expressed  an  interest  in 
DELNET  and  knew  what  capabilities  would  be  most  useful  to 
the  EE  department.  Because  of  this,  seven  EE  faculty 
members  and  two  mathematics  faculty  members  were  chosen  to 
be  interviewed.  Each  of  those  chosen  represented  a  specific 
area  of  interest  and  so  the  results  of  the  interviews 
represented  a  wide  range  of  user  applications. 

Each  user  was  interviewed  for  approximately  forty-five 
minutes  to  an  hour  and  a  half  using  the  user  survey 
described  above.  Personal  interviews  were  chosen  over 
regular  surveys  to  allow  each  user  to  ask  for  clarif ication 
of  the  various  questions,  and  also  in  hope  of  getting  more 
information  from  the  users  than  they  might  have  given  in 
written  responses  to  the  survey.  The  response  to  the  user 
interviews  was  excellent  and  the  information  from  the  user 
survey  was  used  to  formulate  the  general  requirements 
specifications  that  follow. 

EEfliag-t-gd  ilfifig  al  peln_et 

The  user  survey  results  were  used  to  determine  the 
projected  uses  of  DELNET.  The  principal  uses  that  were 
considered  most  beneficial  were  in  the  area  of  resource 
sharing.  Specifically,  peripheral  sharing  and  file  access 
and  transfer  capability  across  DELNET  were  identified  by  all 
users  as  being  of  top  priority.  Next  in  potential  benefits 
was  the  capability  to  access  the  CYBER  750  from  DELNET. 
Access  to  AFITNET,  another  local  computer  network,  being 
developed  to  process  much  of  AFIT's  ever-increasing 
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workload,  was  regarded  as  equally  beneficial  once  this 
network  is  implemented.  Software  tool  sharing  was  also 
identified  as  beneficial  while  access  to  the  ARPANET  was 
considered  of  lesser  benefit.  Distributed  processing  as 
well  as  distributed  databases  received  widely  varying 
evaluations.  Those  with  a  special  interest  in  these  areas 
rated  these  capabilities  as  very  beneficial  while  others 
rated  them  of  little  use.  There  was  a  general  concensus 
that  the  primary  benefits  of  these  capabilities  would  be 
pedagogical  although  one  person  felt  that  the  importance  of 
distributed  processing  would  increase  rapidly  in  the  next 
few  years.  Recause  the  network  was  not  expected  to  support 
critical  functions,  no  need  was  perceived  for  the  network  to 
guarantee  uninterrupted  service  to  the  user  through 
redundancy  and  fault-tolerance.  Fail-soft  capability  was 
regarded  as  beneficial,  however.  The  projected  uses  of 
DELNET  are  summarized  in  Table  1. 

ILsex-priented  Functional  Requirements 

The  users'  functional  requirements  were  also  clarified 
by  the  survey.  The  throughput  required  by  the  users  was 
basically  driven  by  the  need  to  be  able  to  transmit  16-32 
Kbyte  files  between  the  computers  on  the  network  in  less 
than  three  minutes.  Usage  of  the  computers  in  the  Digital 
Engineering  Laboratory  should  average  about  3  to  4  hours  per 
day  with  peaks  of  up  to  almost  24  hours  a  day  for  a  few  days 
at  a  time  on  some  computers  like  the  Data  General  Eclipse. 
The  computers  with  the  heaviest  projected  usage  in  the 
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Table  1 


Projected  Uses  of  DELNET 


Projected  Use 

Very 

Benef icial 

Benef icial 

Somewhat 

Beneficial 

Of  Little 
Use 

Of  Mo 
Use 

Peripheral 

Sharing 

7 

0 

0 

0 

0 

File  Transfers 

5 

2 

0 

0 

0 

Software 

Tool  Sharing 

2 

4 

1 

0 

C 

Access  to 

CYBER  750 

3 

3 

1 

0 

0 

Access  to 
AFITNET 

3 

4 

0 

0 

0 

Distributed 

Processing 

2 

1 

2 

2 

0 

Distributed 

Databases 

2 

0 

2 

3 

0 

Fault 

Tolerance 

0 

1 

1 

3 

2 

Digital  Engineering  Laboratory  are  the  Data  General  Nova, 
the  Data  General  Eclipse,  the  Digital  Equipment  Corporation 
VAX-11/780,  the  Digital  Equipment  Corporation  LSI-lls,  the 
Intel  Series  II  MDS,  the  Digital  Equipment  Corporation 
PDP-lls,  and  the  Microprogrammable  Minicomputer  Emulator 
(MIME)  that  was  built  in  the  Digital  Engineering 
Laboratory . 

The  response  time  requirement  was,  of  course,  closely 
tied  to  the  throughput  requirement.  The  requirement  for 
response  times  was  addressed  for  three  modes:  interactive, 
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file  transfers,  and  echoing  user  inputs.  In  the  interactive 
mode,  two  to  three  seconds  for  "simple"  commands  was 
considered  to  be  satisfactory.  For  file  transfers,  ten  to 
fifteen  seconds  was  given  by  one  user,  although  this  is  not 
feasible  on  many  of  the  Digital  Engineering  Laboratory 
computers  even  when  the  user  is  in  the  local  computer  mode. 
Thus,  the  file  transfer  response  time  was  set  at  three 
minutes  for  a  32  Kbyte  file.  This  was  considered  an 
acceptable  tradeoff  between  user  requirements  and  the  file 
accessing  capabilities  of  the  computers  in  the  Digital 
Engineering  Laboratory.  The  echo  response  time  requirement 
was  given  as  being  a  maximum  of  one-half  second.  This  is  to 
insure  that  the  echoes  of  the  user  inputs  do  not  interfere 
with  their  entering  subsequent  data  at  the  keyboard.  With 
the  exception  of  the  ten  to  fifteen  second  file  transfer 
requirement,  all  other  response  time  requirements  seemed 
consistent  with  the  results  of  psychological  studies 
predicting  satisfactory  levels  of  performance  for  the 
typical  user  (Ref.  13:  322,323).  Another  requirement  on 
the  response  time  was  that  the  standard  deviation  for  the 
distribution  of  response  times  be  less  than  half  the  mean 
response  time  to  the  command.  Thus,  consistency  in  the 
response  times  was  also  considered  important. 

In  addressing  the  requirements  of  the  user  interface, 
the  key  requirement  that  was  mentioned  by  almost  all  users 
was  the  need  to  make  the  network  configuration  and  specific 
operating  systems  of  the  hosts  transparent  to  the  user.  The 
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difficulty  of  achieving  this  was  also  mentioned,  however, 
because  of  the  difficulty  in  concealing  operating  system 
idiosyncrasies.  Other  user  interface  requirements  included 
error  recovery  capabilities  and  the  capability  for  the  user 
to  get  help  from  the  network  through  a  "teach"  command.  One 
user  also  felt  that  the  transparency  should  be  optional  so 
that  the  user  can  access  capabilities  of  the  machines  that 
the  network  command  language  may  not  exploit. 

Security  was  addressed  from  three  perspectives.  All 
users  indicated  that  they  did  not  forsee  the  possibility  of 
running  classified  data  on  any  of  the  computers  in  DEL. 
Thus,  the  concensus  was  that  the  network  did  not  need  to  be 
designed  to  safeguard  the  processing  of  classified 
information.  The  second  aspect  of  security  addressed  the 
requirement  to  protect  files  on  the  network  from 
unauthorized  access  or  alteration.  Two-thirds  of  the  users 
felt  that  this  was  a  requirement  while  one-third  saw  no  need 
for  this  capability.  One  user  also  specified  that  this 
access  control  should  allow  users  to  be  given  various  levels 
of  access  rights  such  as  "read  only".  Thus,  file  access 
restriction  was  found  to  be  a  security  requirement  for  the 
network.  The  third  aspect  of  security  was  access  control  to 
the  network  from  outside  DEL.  Since  gateways  to  the  CYBER, 
AFITNET,  and  possibly  the  ARPANET  were  envisioned,  the  need 
for  access  control  at  these  gatev.  _,s  was  evident. 

Defining  the  availability  of  the  network  was  the  first 
problem  encountered  in  trying  to  assess  the  availability 
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requirement.  The  availability  of  DELNET  was  defined  to  be 
the  percentage  of  time  that  the  network  provided  the 
capabilities  required  by  a  particular  user  as  compared  to 
the  time  that  it  was  supposed  to  provide  those 
capabilities.  This  definition  allowed  the  users  to 
individually  assess  their  requirements  for  network 
availability.  The  assessments  ranged  from  60  percent  to 
nearly  100  percent  with  90  percent  being  the  answer  given  by 
almost  half  of  the  users.  The  time  periods  that  the  network 
should  be  available  were  identified  as  either  during  the 
duty  hours  of  the  Digital  Engineering  Laboratory  technicians 
or  during  the  hours  that  the  CYBER  750  is  available.  The 
lower  percentages  were  given  by  those  who  stated  what  they 
felt  would  meet  their  needs,  while  the  highest  percentage 
was  given  because  the  user  felt  that  this  should  be  fairly 
easy  to  achieve.  The  90  percent  availability  level  met  all 
stated  requirements  of  the  users  who  were  interviewed  and 
thus  represents  a  reasonable  target  goal  for  the  system 
design.  The  u s e r -o r i ented  functional  requirements  are 
summarized  in  Table  2. 

D££lgnr.prie.n.ted  Functional  Requirements 

The  design-oriented  requirements  included  flexibility, 
performance  monitoring,  and  pedagogical  requirements.  The 
flexibility  requirement  was  addressed  by  asking  the  users  to 
describe  how  they  would  see  the  network  changing  over  the 
next  five  years.  The  response  given  by  almost  all  was  that 
more  hosts  and  devices  would  be  added  to  the  network.  All 
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Table  2 


User-oriented  functional  Requirements 


Area 

Not 

Applicable 

Marginally 

Applicable 

Applicable 

Very 

Applicable 

Essential 

Throughput 

1 

1 

3 

2 

0 

Response 

Time 

0 

1 

2 

3 

1 

User 

Interface 

0 

0 

1 

3 

3 

Security 

2 

1 

1 

1 

2 

0 

1 

1 

3 

2 

the  users  felt  that  it  was  very  important  for  DELNET  to  be 
easily  r econf igu r able  with  respect  to  adding  new  hosts  and 
devices.  Other  changes  mentioned  included  increased  use  of 
the  network  by  those  outside  the  Digital  Engineering 
Laboratory  and  a  transition  of  the  network  workload  from 
predominantly  file  transfers  to  more  interactive  bursty 
traffic.  Flexibility  with  respect  to  the  topology, 
protocols;  and  transmission  medium  were  generally  considered 
requirements  only  from  the  pedagogical  point  of  view.  One 
user  also  felt  that  it  was  important  to  be  able  to  vary 
between  serial  and  parallel  bit  transmission. 

The  need  for  some  form  of  performance  monitoring 
capability  was  expressed  by  all  users.  They  felt  that 
statistics  of  the  traffic  through  each  node  as  well  as 
accounting  data  collection  on  user  jobs  were  both  important 
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to  monitor.  Both  hardware  and  software  monitor  capabilities 
were  stated  as  requirements  by  two  of  the  users  and  another 
user  suggested  incorporating  a  performance  monitoring  node 
into  the  network.  Thus,  although  the  capability  to  monitor 
the  performance  of  DELNET  was  considered  important  by  all 
users,  the  requirements  for  implementing  this  capability 
varied  significantly. 

The  pedagogical  functional  requirements  given  by  the 
users  are  basically  reflected  in  the  requirements  above  for 
flexibility  and  performance  monitoring.  Another  pedagogical 
requirement  that  was  expressed  was  that  DELNET  should  have 
the  capability  to  evaluate  the  use  of  fiber  optic  links  in 
computer  networking. 

Given  the  possibility  of  implementing  a  distributed 
processing  capability,  the  requirements  for  a  distributed 
processing  language  that  would  be  available  on  all  machines 
were  assessed.  Pascal  was  mentioned  by  all  users  (one 
specified  UCSD  Pascal)  and  Ada  and  FORTRAN  were  mentioned  by 
almost  all.  BASIC  was  mentioned  by  one  user  and  one  user 
stressed  the  capabilities  that  Ada  would  have  in  distributed 
processing  due  to  its  powerful  control  structures. 

The  users  were  also  asked  to  rank  each  of  the 
functional  requirement  areas  on  a  scale  from  not  applicable 
to  essential.  Flexibility  received  the  highest  overall 
rating  falling  between  very  applicable  and  essential.  The 
user  interface,  the  availability,  performance  monitoring 
capability,  and  the  pedagogical  requirements  were  all  rated 
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as  very  applicable.  The  response  time  requirements  fell  a 
little  lower  between  applicable  and  very  applicable,  while 
the  throughput  requirement,  security,  and  the  requirement 
for  a  distributed  processing  language  were  only  considered 
as  applicable.  The  design-oriented  functional  requirements 


Table  3 

Design-oriented  Functional  Requirements 


are  summarized  in  Table  3. 

Other:  Hast  Requi remen ts 

The  third  section  of  the  user  interview  produced  eight 
additional  requirements  for  the  network.  One  requirement 
was  that  the  network  have  a  general  interface  port  where 
student  digital  hardware  design  projects  could  be  interfaced 
to  the  network.  Another  request  was  that  the 
intercommunication  between  the  hosts  and  the  network  be 
interrupt-driven.  The  ability  to  find  a  file  in  the  network 
that  had  been  sent  from  one  host  to  another  was  also 
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mentioned  as  a  requirement.  One  user  felt  that  there  was  a 
very  great  danger  of  letting  the  potential  capabilities  of 
DELNET  determine  how  it  would  be  used  rather  than  addressing 
how  DELNET  could  best  fulfill  the  needs  of  the  Digital 
Engineering  Laboratory.  In  particular,  he  felt  that  the 
DELNET  should  not  be  used  for  general  software  development 
but  rather  that  this  should  be  done  on  the  CYBER  750.  It 
was  pointed  out  by  another  user  that  the  requirement  to  have 
all  hosts  available  on  the  network  is  probably  only 
applicable  about  one  percent  of  the  time  when  computer 
networking  research  is  being  accomplished.  Another  user 
felt  that  DELNET  should  be  able  to  be  easily  initialized  to 
contain  an  arbitrary  subset  of  the  hosts  available  in  the 
network.  The  number  of  terminals  and  their  locations  was 
another  requirement  that  a  user  felt  needed  to  be 
addressed.  Another  user  felt  that  the  network  should  serve 
as  a  testbed  for  the  Universal  Network  Interface  Device 
(UNID)  that  is  also  being  developed  here  at  AFIT  and  should 
be  ready  for  testing  shortly  (Refs.  4,18).  Finally,  one 
user  stated  that  top-down  decomposition  and  structured 
analysis  should  be  used  in  the  design  process. 

Constraints  sn  PELNES 

Another  requirement  of  DELNET  was  that  its  cost  of 
implementation  be  less  than  $10,000  per  year  until  1983  when 
an  additional  $30,000  will  be  available  for  the  network. 

The  noise  environment  was  also  assessed.  Although  +100 
volt  variations  in  the  voltage  levels  from  the  building 
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power  supply  have  been  observed,  the  Digital  Engineering 
Laboratory  has  its  own  power  supply  that  can  be  used.  Also, 
while  noise  contributions  from  all  the  computers  and  other 
electronic  devices  in  the  Digital  Engineering  Laboratory 
might  be  expected  to  be  extensive,  no  problems  attributable 
to  a  noisy  environment  have  been  encountered  using  twisted 
pair  to  link  such  computers  as  the  LSI-lls. 

The  physical  layout  of  the  computers  also  had  to  be 
addressed.  The  computers  that  are  candidates  for  the  DELNET 
are  all  in  the  same  building,  on  the  same  floor,  and  located 
in  four  adjacent  rooms.  The  maximum  separation  of  any  two 
computers  is  about  125  feet.  A  floor  plan  showing  the 
locations  of  all  minicomputers  having  s em i - pe r manen t 
locations  in  the  Digital  Engineering  Laboratory  is  included 
in  this  paper  as  Appendix  B. 

Finally,  the  maintainability  requirement  of  the  network 
had  to  be  determined.  In  order  to  minimize  the  difficulties 
involved  in  maintaining  DELNET,  all  software  must  be 
thoroughly  documented  and  the  hardware  should  be  designed 
for  easy  modular  replacement.  This  will  allow  a  faulty 
module  to  be  quickly  replaced  with  a  spare  while  it  is  being 
repaired  so  that  DELNET  can  continue  to  be  available. 

Summaxy 

Through  the  results  of  the  user  survey  it  was  possible 
to  specify  not  only  a  comprehensive  list  of  functional 
requirements  but  also  to  estimate  their  relative 
importance.  The  ability  to  transfer  files  across  the 


network  and  to  share  peripherals  attached  to  other  hosts  on 
DELNET  were  the  two  most  important  uses  and  those  that  the 
users  wished  to  see  implemented  first.  Flexibility  was 
considered  the  most  important  functional  requirement;  and 
the  user  interface,  availability,  performance  monitoring 
capability,  and  the  pedagogical  requirements  were  also 
considered  very  important.  Finally,  other  constraints  such 
as  development  funds  available,  the  physical  location  of  the 
hosts,  and  the  noise  environment  were  assessed.  Appendix  A 
contains  a  complete  compilation  of  the  user  survey  results. 


25 


III.  DELNET 


inliiadagjLiflD 

This  chapter  translates  the  general  functional 
requirements  addressed  by  the  last  chapter  into  more 
detailed  system  specifications.  The  first  section  of  this 
chapter  addresses  the  system  hardware  requirements  while  the 
second  section  specifies  the  system  software  requirements. 
The  principal  hardware  system  requirements  to  be  addressed 
are  the  network  topology,  the  host  computers  to  be  included 
in  the  network,  the  selection  of  a  suitable  node  for  the 
netv/ork,  and  a  choice  of  appropriate  transmission  mediums 
for  the  links  on  DELNET.  The  system  software  requirements 
are  specified  using  DeMarco's  Structured  Analysis  technique 
(Ref.  6).  A  very  abbreviated  description  of  the  components 
of  the  technique  is  given  and  its  use  is  justified.  Then, 
Structured  Analysis  is  used  to  specify  the  system  software 
requirements  at  the  user  level,  the  applications  level,  the 
host-to-host  level,  the  network  protocol  level,  and  the  link 
protocol  level.  Finally,  the  physical  protocol 
specifications  are  stated. 

The  requirements  specification  was  actually  an 
iterative  process.  While  some  of  the  specifications  found 
in  this  chapter  could  be  derived  directly  from  the 
functional  requirements,  many  actually  followed  from  design 
decisions  made  in  the  following  chapter.  These  requirements 
would  then  trigger  new  design  decisions  which  might  in  turn 
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modify  the  requirements  specification  further.  What 
follows,  then,  is  the  final  results  of  this  iterative 
process. 

System  Hardware  Reauirefflgatg 

The  functional  requirements  of  Chapter  2  can  be  used  to 
derive  rather  detailed  specifications  of  the  hardware  that 
is  required.  This  is  done  in  the  following  sections  by 
considering  how  the  functional  requirements  of  the  system 
place  constraints  on  the  system  hardware.  These  constraints 
are  then  used  to  derive  the  more  detailed  hardware 
specifications . 

Topology.  The  primary  requirement  for  the  topology 
was  that  identified  by  Ravenscroft  and  mentioned  earlier  — 
that  the  topology  had  to  be  flexible,  and  must  lend  itself 
to  easy  expansion  through  the  addition  of  more  hosts  and 
nodes.  However,  the  topology  also  must  not  have  bottlenecks 
that  will  limit  the  throughput  on  the  network  below  the 
required  level  or  that  will  increase  the  response  time  to 
unacceptably  high  levels  due  to  queueing  delays.  The 
response  time  requirement  may  also  impact  the  topology  by 
limiting  the  number  of  nodes  between  any  two  host  computers 
since  the  combined  queueing  delays  may  increase  the  response 
time  to  an  unacceptable  level.  Since  availability  was  not  a 
major  concern,  the  topology  need  not  be  overly  redundant. 

H£.£i  •  The  requirements  for  the  host 
computers  to  be  included  in  DELNET  principally  reflected 
their  usefulness  from  a  pedagogical  viewpoint,  their 
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capabilities,  and  their  peripherals.  DELNET  should  allow 
computers  to  be  added  to  the  network  easily,  regardless  of 
their  sophistication.  So,  there  was  a  requirement  for  both 
a  simple  microcomputer  and  a  sophisticated  minicomputer  to 
be  included  in  DELNET  to  demonstrate  DELNET's  capability  to 
interface  with  both.  Also,  since  peripheral  sharing  was  a 
major  projected  use,  those  computers  with  the  most  powerful 
peripherals  should  be  included  in  DELNET.  finally,  the 
usefulness  of  the  network  would  be  enhanced,  if  those 
computers  used  most  often  in  the  Digital  Engineering 
Laboratory  were  included  in  DELNET. 

Nodes .  The  requirements  for  the  nodes  in  the  network 
also  were  addressed.  Because  DELNET  is  to  be  as  transparent 
to  the  users  as  is  practical,  it  should  not  noticeably 
degrade  the  performance  of  the  host  computers  when  they  are 
included  in  the  network.  Thus,  the  nodes  must  be  capable  of 
handling  lower-level  network  protocols.  The  nodes  should 
also  be  easily  reconfigured  to  accomodate  various  topologies 
and  also  must  be  capable  of  meeting  the  network  throughput 
requirements.  Furthermore,  the  node  should  have  the 
capability  of  being  easily  reprogrammed  for  different 
protocols  and  should  be  able  to  collect  performance 
monitoring  statistics.  Finally,  if  possible,  a  compiler 
should  be  available  for  the  CPU  that  the  node  is  based  on  so 
that  the  protocol  software  may  be  written  in  a  higher  order 
language.  This  would  reduce  the  magnitude  of  the 
implementation  effort  and  enhance  the  maintainability  of  the 
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software 


Ti 3ns mission  Medium.  There  are  several  system 
requirements  for  the  transmission  medium  as  well.  First,  it 
must  support  the  data  transmission  rates  necessary  to  meet 
the  throughput  and  response  time  requirements.  Second,  it 
must  provide  reliable  communications  links  to  avoid 
degrading  throughput  and  response  times.  Otherwise,  if  a 
high  percentage  of  blocks  of  data  required  retransmission 
then  both  response  time  and  throughput  would  suffer.  The 
same  would  be  true  if  forward  error  correction  was  used  and 
a  high  degree  of  redundancy  was  required.  On  the  other 
hand,  there  is  no  requirement  that  the  transmission  medium 
provide  secure  communications  or  provide  high  noise 
immunity.  The  transmission  medium  should  be  easily 
re-routed,  however,  to  allow  the  topology  to  be  easily 
reconfigured.  Finally,  at  least  one  link  in  DELNET  should 
make  use  of  fiber-optic  technology  to  satisfy  the 
pedagogical  requirement  stated  in  the  user  survey. 

Structured  Specification  of  the  Protocol  Requirements 

IniX.Qd.ucii&ii .  While  the  user  surveys  provided  an 
excellent  tool  for  specifying  the  functional  requirements 
for  DELNET,  and  even  some  of  the  more  hardware-related 
system  requirements,  a  technique  was  needed  to  translate  the 
DELNET  functional  requirements  into  system  software 
requirements.  Several  techniques  were  available  for  this 
task  including  DeMarco's  Structured  Analysis  (Pef  .  6)  , 
SofTech's  Structured  Analysis  and  Design  Technique  (SADT) 
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(Ref.  19),  IBM's  hierarchical  input-process-output  (HIPO) 
diagrams  (Ref.  15:  17,18),  and  various  problem  statement 
languages  (Ref.  2).  Structured  analysis  was  chosen  as  the 
technique  to  be  used  to  translate  the  functional 
requirements  into  the  system  software  requirements  due  to 
several  advantages  that  it  offers.  However,  before  these 
advantages  can  be  understood,  it  is  necessary  to  understand 
the  basic  components  of  the  Structured  Analysis  technique. 

Structured  analysis  is  a  technique  using  data  flow 
diagrams  (DFD's)  and  a  data  dictionary  which  uses  Structured 
English,  decision  tables,  and  decision  trees  to  describe  the 
DFD's.  The  DFD's  have  the  four  components  shown  in  Figure 


1.  The  first  component  is  the  data  flow.  It  is  a  "pipeline" 
of  other  data  flows  and  of  data  elements.  The  data  elements 
are  the  basic  data  types  that  cannot  be  partitioned  further 
and  still  retain  their  meaning.  A  data  element  might  be  a 
three-digit  integer  representing  the  length  of  a  file  in 
bytes  or  a  seven-letter  word  representing  a  command  type. 


The  data  flow  is  represented  by  a  curved  arrow  on  the 
DFD's.  The  process  converts  input  data  flows  to  output  data 
flows  and  is  the  second  component  of  the  DFD’s.  It  is 
represented  by  a  circle  or  bubble  that  contains  the  process 
name.  The  boxes  represent  the  third  component  of  DFD’s,  the 
sources  and  sinks  of  information.  They  may  represent  a  user 
keyboard,  a  user  display,  or  any  other  mechanism  by  which 
information  enters  or  leaves  the  system.  Finally,  files  are 
the  last  component  and  are  repositories  of  information 
within  the  system.  They  are  shown  by  straight  lines.  The 
DFD’s  are  layered  starting  with  a  context  diagram  that 
defines  the  interface  of  the  system  with  its  environment. 
Then  the  processes  in  the  diagram  are  expanded  into 
lower-level  DFD’s.  This  partitioning  process  continues 
until  the  data  flows  entering  and  leaving  a  process  consist 
of  only  one  data  element  each.  At  this  point,  a  process 
description  is  written  for  the  process  and  the  process  is 
not  expanded  into  a  lower-level  diagram.  The  process 
descriptions,  data  flow  and  data  element  descriptions,  and 
file  descriptions  for  all  the  DFD’s  are  compiled  into  the 
data  dictionary. 

With  the  very  abbreviated  description  of  Structured 
Analysis  given  above,  it  is  now  possible  to  examine  eight  of 
the  advantages  that  Structured  Analysis  offers.  First,  it 
was  based  upon  the  concept  of  partitioning.  This  allowed 
the  complex  network  requirements  to  be  addressed  abstractly 
at  the  user  level  where  “-he  context  diagram  could  represent 


31 


the  interface  that  the  user  wished  to  make  to  the  system. 
Then  lower  level  diagrams  could  be  used  to  refine  the  data 
flows  and  processes  in  the  higher  level  diagrams  to 
sufficient  detail.  Thus,  this  method  of  partitioning 
allowed  the  large  and  complex  DELNET  requirements  problem  to 
be  approached  in  an  orderly  manner  rather  than  causing  the 
analyst  to  be  overwhelmed  by  the  volume  of  requirements  to 
be  specified.  Second,  through  the  use  of  a  data  dictionary 
and  the  concentration  on  data  flows  rather  than  processes, 
Structured  Analysis  allowed  the  interfaces  to  be  more 
clearly  defined--in  fact,  it  practically  forced  this  to 
occur.  Third,  the  process  definitions  could  be  easily 
specified  using  Structured  English,  a  tool  incorporated  into 
structured  analysis.  Fourth,  the  structured  specification 
consisting  of  the  data  flow  diagrams  and  data  dictionary  was 
organized  to  eliminate  redundancy  in  the  structured 
s pec i f i ca t i on .  This  made  the  task  of  maintaining  the 
specification  and  changing  it  much  easier.  Fifth,  the  data 
flow  diagrams  were  a  two-dimensional  presentation  of  the 
requirements  and  thus  presented  the  structure  of  the  DELNET 
requirements  much  clearer  than  the  linear,  voluminous 
presentation  of  a  traditional  specification.  Sixth, 
Structured  Analysis  differentiated  between  the  logical  and 
the  physical  environment,  thus  more  clearly  defining  the 
problem.  This  was  also  very  helpful  since  this  allowed  the 
functional  software  requirements  to  be  specified  without 
being  concerned  about  the  actual  hardware  that  would  execute 


those  requirements.  Seventh,  when  a  data  flow  diagram  was 
wrong,  it  was  usually  glaringly  wrong,  and  thus  it  was 
easier  to  spot  inconsistencies  and  gaps  in  the  structured 
specification  and  to  correct  the  deficiencies.  Finally,  it 
was  fairly  easy  to  transition  from  the  structured 
specification  to  the  design  phase  since  the  data  flow 
diagrams  gave  a  first  cut  at  the  module  structure  charts 
(for  Yourdon  and  Constantine's  structured  design  technique) 
using  Source/Transform/Sink  analysis  (Refs.  6,22).  The 
major  disadvantage  was  that  it  was  very  time  consuming  to 
generate  the  structured  specification.  However,  the  extra 
time  spent  in  the  requirements  definition  was  probably  more 
than  recompensed  by  the  time  saved  in  the  design  phase  and 
the  benefits  of  having  less  requirements  errors. 

Context  Diagram.  The  context  data  flow  diagram  shows 
the  system  boundary  and  interface  with  the  user.  As  can  be 
seen  in  Figure  2,  the  network  operating  system  (NOS)  must 
include  everything  between  the  user  input  from  a  keyboard 
that  is  connected  to  a  computer  in  the  network,  to  the 
response  that  the  user  receives  at  his  display.  Thus,  the 
NOS  includes  all  the  computer  operating  systems  in  the 
network  as  well  as  all  interface  software  and  hardware 
required  to  implement  the  network  functional  requirements. 
To  initialize  the  network,  a  configuration  bootstrap  process 
is  also  required.  In  addition.  Table  4  shows  the  layers  of 
protocol  that  are  defined  in  the  sets  of  DFDs  that  follow. 
Table  5  describes  the  process  hierarchy  for  the  first  set  of 
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DFDs ,  the  Network  Operating  System. 

System  Diagram.  The  system  diagram  translates  the  key 
functional  requirements  into  the  software  requirements  for 
the  NOS  as  shown  in  Figure  3.  First,  the  user  command  must 
be  examined  to  determine  whether  it  is  a  network  command  or 
a  local  command  (1) .  If  it  is  a  network  command,  then  it 
must  be  sent  to  the  computer  with  the  software  to  interpret 
the  network  command  (2).  The  transmitted  network  command 
must  then  be  classified  as  either  a  command  to  transfer  a 
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Table  5 


If 


Network  OEe rating  System  Process  H i e_c ai chy 


1.  Determine  Command  Type 

2.  Send  Command  to  Host  with  NOS 

3.  Determine  Network  Command  Type 

4.  Transfer  File 

4.1  Send  Get-File  Command  to  File  Source  Host 

4.2  Get  File  from  Source  Device 

4.3  Restructure  File  for  Network 

4.4  Transmit  File  to  Destination 

4.4.1  Divide  File  into  Blocks 

4.4.2  Transmit  Block 

4.4.3  Reassemble  Blocks 

4.5  Restructure  File  for  Dest  Host 

4.6  Store  File  on  Dest  Device 

5.  Control  Session 

5.1  Determine  Session  Control  Command  Type 

5.2  Log  User  Into  Network 

5.3  Log  User  Out  of  Network 

6.  Help  User 

6.1  Determine  Help  Info  Requested 

6.2  Provide  General  Network  Introduction 

6.3  Provide  Procedure  for  Transferring  Files 

6.4  Provide  List  of  Active  Hosts  and  Devices 

6.5  Provide  Procedure  for  Logging  Out  of  Network 

7.  Send  Message  to  User's  Host 

8.  Route  Local  Command 

9.  Execute  Routed  Local  Command 

10.  Route  Local  Response 


file  from  one  device  on  the  network  to  another  device,  a 
command  to  log  into  or  log  out  of  the  network,  or  a  request 
for  help  in  using  the  network  (3).  First,  if  the  request  is 
to  transfer  a  file,  then  the  NOS  must  check  the  network 
configuration  to  insure  that  the  command  is  valid.  Then  the 


NOS  must  attempt  to  transfer  the  file  and  a  file  transfer 
message  must  be  output  and  also  entered  into  the  file 
transfer  log  (4) .  Second,  if  the  transmitted  network 
command  is  to  log  into  or  log  out  of  the  network,  then  a  log 
in  or  log  out  message  must  be  output  and  the  command  routing 
table  must  be  updated.  The  file  transfer  log  and  the 
network  configuration  file  must  both  be  accessed  by  the 
process  (5).  Third,  if  the  transmitted  network  command  is  a 
help  request,  then  the  appropriate  help  information  must  be 
output  to  the  user.  Depending  upon  the  type  of  help 
request,  this  process  may  require  access  to  the  network 
configuration  file  (6) .  Finally,  the  response  that  has  been 
output  from  one  of  the  three  processes  must  be  transmitted 
back  to  the  user  as  the  network  response  (7) . 

If  the  user  command  was  a  local  command,  then  the 
command  must  be  routed  to  the  computer  that  the  user 
specified  in  his  log  in  command  to  DELNET.  Since  this  does 
not  have  to  be  the  host  to  which  the  user  terminal  is 
physically  attached,  the  command  routing  table  must  be 
accessed  to  determine  this  routing  (8).  At  the  host  to 
which  the  user  is  local,  the  command  must  be  executed  and  a 
local  response  must  be  generated  (9).  Finally,  this  local 
response  must  be  routed  to  the  user  (10).  In  processes  3, 
4,  5,  6,  and  9  there  is  also  the  possibility  for  commands  to 
be  invalid,  and  thus,  error  messages  must  be  generated  in 
place  of  the  expected  response. 

Eil£  Iianslzz  ££SJ1  i££m£Di.£.  The  transfer  file 
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process  was  specified  in  more  detail  by  the  lower  level  DFD 
shown  in  Figure  4.  At  this  level,  the  transmitted  file 
transfer  command  must  be  parsed  and  the  file  transfer 
command  parameters  must  be  used  to  generate  a  get-file 
command  that  must  be  sent  to  the  host  that  has  the  file  to 
be  transferred  (4.1)  .  The  source  host  must  then  retrieve 
the  file  from  the  device  that  it  is  stored  on  and  must 
restructure  the  file  to  a  standard  network  file  structure 
(4. 2, 4. 3).  Then  the  file  must  be  transmitted  to  its 
destination  using  information  also  from  the  get-file  command 
(4.4).  Checkpointing  must  be  used  to  transmit  the  file  to 
insure  that  the  entire  file  does  not  have  to  be 
retransmitted  if  an  error  should  occur,  but  rather  only  the 
last  portion  to  be  transmitted.  This  is  necessary  to  insure 
adequate  throughput  and  response  time.  This  checkpointing 
mechanism  is  shown  in  Figure  5.  The  file  is  broken  into 
blocks  which  are  individually  transmitted  (  4 . 4 . 1 , 4 . 4 . 2)  . 
Thus,  only  those  blocks  not  yet  received  correctly  need  to 
be  transmitted  when  a  file  transmission  error  occurs.  At 
the  destination  host,  the  file  must  be  restructured  for  that 
host  (4.5) .  Finally,  the  file  must  be  stored  on  the 
destination  device  and  the  file  transfer  message  output  and 
entered  into  the  file  transfer  log  (4.6).  There  must  be 
error  messages  generated  if  the  file  cannot  be  retrieved 
from  the  source  device  or  if  the  destination  device  cannot 
store  the  file. 

Session  Control  Requirements .  The  control  session 


38 


process  may  also  be  specified  further  and  its  lower  level 


DFD  is  shown  in  Figure  6.  The  transmitted  session  control 
command  must  be  classified  as  either  a  log  in  command  or  a 
log  out  command  (5.1).  If  it  is  a  log  in  command,  then  the 
command  must  be  validated  by  accessing  the  network 
configuration  file  to  insure  that  the  host  exists  in 
DF. LNET.  Then  a  log  in  message  must  be  output  and  the 
command  routing  table  must  be  updated  to  show  the  local  host 
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for  that  user  (5.2).  If  the  transmitted  session  control 
command  is  a  log  out  command,  then  the  command  routing  table 
must  be  reset  to  the  host  to  which  the  user  is  physically 
attached  and  a  log  out  message  output  to  the  user  display 
(5.3)  . 

iLelP  U.S.£.I  ££31iiX£iIl£  .  Finally,  the  help  user 
process  may  be  specified  further  by  the  lower  level  DFD 


Figure  7  Help  Iteer  (6.0)  HD 


shown  in  Figure  7.  The  transmitted  help  request  must  be 
classified  as  either  a  general  information  request,  a  file 
transfer  procedure  request,  a  list  of  active  host  and  device 
names  request,  or  a  session  control  information  request 
(6.1)  .  If  it  is  a  general  information  request,  then  a  menu 
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selection  consisting  of  the  available  commands  and  their 
formats  must  be  output  along  with  the  formats  for  the  more 
specific  help  requests  (6.2)  .  If  the  transmitted  help 
request  is  a  file  transfer  procedure  request,  then  the 
format  for  the  transfer  file  command  must  be  output  (6.3) . 
If  the  transmitted  help  request  is  a  list  of  active  hosts 
and  device  names  request,  then  this  list  must  be  output  by 
accessing  the  network  configuration  file  (6.4).  Finally,  if 
the  transmitted  help  request  is  a  session  control 
information  request,  then  the  information  on  the  session 
control  commands  must  be  output  (6.5). 

Host-to-Host  Protocol  Requirements .  The  previous 
protocol  requirements  were  specified  to  implement  the 
applications  of  remotely  logging  into  a  computer  and 
transferring  files.  These  as  well  as  the  user  help  protocol 
rely  upon  a  host-to-host  transfer  mechanism  which  was 
treated  as  a  primitive  by  these  processes.  If  the  DFD 
partitioning  process  had  been  followed  as  specified  by 
DeMarco,  then  the  partitioning  of  the  host-to-host  transfer 
mechanism  would  have  been  duplicated  several  times. 
However,  by  defining  the  host-to-host  transfer  mechanism  as 
a  primitive  that  is  used  by  several  processes,  it  was 
possible  to  start  a  new  set  of  DFDs  for  this  mechanism 
without  having  to  duplicate  them  for  each  process.  Table  6 
shows  the  overall  process  hierarchy  for  this  set  of  DFDs. 

The  context  diagram  for  the  host-to-host  protocol  is 
shown  in  Figure  R.  Obviously,  the  most  important  function  of 
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Table  6 


llg-Slr^orilgsl  PcQ-tocol  Process  Hierarchy 

Execute  Cal  lino  Host  Protocol 

1.1  Divide  Data  Into  Packet  r. 

1.?  Place  Channel  in  Data  Transfer  State 

1.?  Window  Calling  Host  to  Called  Pont  Data  Packet. 

1.4  Send  Packet  to  Calling  Node 

1  .  6  Determine  Calling  Node  to  Calling  Port  Packet  Tv 

1.6  Determine  Data  Packet  Category  and  extract  Plow 

1.7  Buffer  Packet  Seouence 

1.8  Assemble  Packet  Seauence 

1.9  Confirm  Receipt  of  Interrupt  Packet 

1.10  Send  Data  to  Calling  Host 
Fxeeute  Calling  Node  Protocol 

?.l  Execute  Calling  Host  Packet 

2.1.1  Determine  Calling  Host  Packet  Type 

7.1.2  Notify  Called  Node  of  Incoming  call 

2.1.7  Update  Calling  Node  Windowing  Variables 

2.1.4  Confirm  Receipt  of  Calling  Host  Interrupt 

7.1.6  Confirm  Calling  Host  Clear  Packet 

2.1.6  Confirm  Calling  Host  Perot  Packet 

2.1.7  Confirm  Calling  Host  Restart  Packet 

2.2  Send  Packet  onto  Network 

2.7  Execute'  Routed  Called  Node  Racket 

2.7.1  Determine  Called  Node  Packet  Typr 

2.7.2  Interrupt  Calling  Node  to  Calling  Port  Pat 

2.7.7  Notify  Calling  Host  of  Call  Connect i cn 

2.7.4  Window  Called  Host  to  Calling  Host  Data  r a 

2.4  Send  Packet  to  Calling  Most 

2.6  Recover  from  Procedure  Prior 
Route  Packets 

Execute  Called  Node  Protocol 

4.1  Execute  Called  Host  Packet 

4.1.1  Determine  Called  Host  Packet  Type 

4.1.2  Relav  Call  Acceptance  to  Calling  Node 

4.1.3  Update  Called  Node  Windowing  Variables 

4.1.4  Confirm  Receipt  of  Called  Host  Interrupt 

4.1.6  Confirm  Called  Host  Clear  Request 

4.1.6  Confirm  Called  Host  Reset  Request 

4.1.7  Confirm  Called  Host  Restart  Request 

4.2  Send  Packet  onto  Network 

4.3  Execute  Routed  Calling  Node  Packet 

4.3.1  Determine  Calling  Node  Packet  Type 

4.3.2  Interrupt  Called  Node  to  Called  Host  Data 

4.3.7  Notify  Called  Host  of  Incoming  Call 

4.3.4  Wirdow  Calling  Host,  to  Called  Host  Data  Fa 

4.4  Send  Packet  to  Called  Host 

4.6  Recover  from  Procedure  Error 
Execute  Called  Host  Protocol 

'-.l  Divide  Data  into  Packets 

6.?  Keep  Channel  in  Data  Transfer  State 

6.3  Winnow  Called  Post  to  Calling  Host  Data  racket 

6.4  Send  Packet  to  Called  Node 

6.5  Determine  Called  Node  to  Called  Host  Packet  Type 

6.6  Determine  Data  racket  Category  and  Extract  Flow 
c . 7  Buffer  racket  Sequence 

6  .  P  Assemble  Packet  Sentience 

6.9  Confirm  Receipt  of  Interrupt  Packet 

6.10  Send  Data  to  Called  Post 
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this  protocol  is  to  transmit  data  from,  the  source  host  to 
the  destination  host.  However,  to  accomplish  this  function 
reliably,  there  must  be  acknowledgement  of  the  transferred 
data  as  well  as  error  recovery  procedures.  Furthermore, 
that  protocol  must  be  transparent  to  the  data  since  the  data 
may  be  in  ASCII,  EBCDIC,  or  binary  form.  Since  both  long 
files  and  short  network  commands  will  be  transmitted  over 
the  network;  unless  special  precautions  are  taken,  a  long 
file  transfer  could  easily  degrade  the  response  time  of  a 
network  command  to  an  unacceptable  level.  Thus,  either  file 
transfers  must  be  able  to  be  interrupted  to  allow  network 
commands  to  be  transmitted  or  separate  mechanisms  must  be 
used  for  file  transmission  and  network  command 
transmission.  The  second  option  would  require  twice  as  many 
resources  as  the  first  alternative  and  so  is  not  an 
acceptable  alternative  if  the  requirements  can  be  met  using 
the  first  option.  The  first  option  requires  that  the 
transmission  medium  be  shared.  Time  division  multiplexing 
(TDM)  or  frequency  division  multiplexing  ( FDM )  could  provide 
multiple  paths  between  any  two  hosts  as  could  many 
topologies.  However,  since  the  throughput  requirement  is 
much  lower  than  the  channe]  capacity  between  hosts  on 
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DEI, NET,  FDM  was  not  a  cost-effective  way  to  meet  the 
response  time  requirement.  Also,  restricting  the  topology 
to  one  having  multiple  paths  between  hosts  conflicted  with 
the  flexibility  requirement.  Thus  some  form  of  TDM  was 
needed.  Packet-switching  enables  the  communications  path 
between  two  hosts  to  be  shared  by  creating  logical  channels 
on  the  path.  Each  channel  is  limited  to  using  the 
communications  path  only  up  to  the  time  required  to  transmit 
a  maximum-length  packet.  This  prevents  the  network  commands 
from  being  blocked  by  large  file  transfers  and  thus  allows 
the  response  time  requirement  to  be  met. 

Thus,  a  packet-switching  protocol  was  required  for 
DEI, MET.  Due  to  time  constraints  on  the  development  of 
DELNET,  this  protocol  should  be  one  that  is  a  standard  and 
thus,  already  specified.  The  alternatives  for  this  protocol 
included  the  ARPANET  protocol,  IBM's  SNA,  and  the  X.25 
protocol.  Because  the  ARPANET  protocol  was  the  first 
packet-switching  protocol,  it  does  not  employ  the  protocol 
advances  such  as  the  newer  bit-oriented  protocols  for 
control  of  the  links.  IBM's  SNA  was  not  designed  for 
heterogeneous  computer  networks  and  thus,  is  not  appropriate 
for  DELNET.  For  these  reasons  and  also  because  of  its 
versatility  and  endorsement  by  the  International 
Consultative  Committee  on  Telephones  and  Telegraphs  (CCITT) , 
the  X.25  protocol  was  chosen  for  DELNET  (Ref.  9:  243-284). 

Overview  of  the  £.2£  Protocol .  The  X.25  protocol  was 
developed  to  provide  a  transport  mechanism  for  data  access 
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across  a  packet-switched  network.  It  includes  the  three 
basic  facilities  of  error  control,  flow  control,  and 
synchronization.  There  are  three  levels  or  layers  within 
the  X.25  protocol.  Level  1  defines  the  physical  protocol 
requirements  and  the  link  protocol  is  defined  by  level  2. 
The  interface  between  hosts  on  the  network  with  their  entry 
nodes  is  specified  by  level  3  of  the  protocol.  The  software 
requirements  for  this  protocol  were  then  developed  using  a 
top-down  approach  by  considering  levels  3,  2,  and  1  in  that 
order . 

X.25.  Level  2  Requirements.  The  transmit  data  process 
shown  in  Figure  8  must  be  slightly  modified  for  the  X.25 
protocol.  This  is  because  the  X.25  protocol  establishes 
virtual  circuits  and  virtual  calls  between  the  hosts  on  the 
network  and  then  allows  a  two-way  exchange  of  data  between 
the  hosts.  Thus,  a  more  accurate  context  diagram  of  the 
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X.25  protocol  is  shown  in  Figure  9.  The  exchange  data 
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process  is  expressed  in  more  detail  by  the  X.25  Level  3 
Overview  DFD  shown  in  Figure  10.  To  make  the  diagrams  more 
readable,  the  terms  "data  terminal  equipment"  (DTE)  and 
"data  communications  equipment"  (DCE)  used  in  the  CCITT 
speci f ica ti on  have  been  replaced  by  the  terms  "host"  and 
"node"  respectively.  Processes  1,  2,  4,  and  5  in  Figure  10 
are  performed  directly  by  the  level  3  protocol  while  Process 
3  uses  a  routing  algorithm  and  the  level  2  protocol  to 
perform  its  function. 

Filins  iLQ.si  Protocol  111  Process .  The 
lower-level  DFD  of  the  Execute  Calling  Host  Protocol  (1) 
process  is  shown  in  Figure  11.  The  data  to  be  sent  from  the 
calling  host  must  be  divided  into  128-byte  packets  (1.1). 
These  packets  must  then  be  queued  to  be  transmitted  to  the 
called  host  over  the  X.25  channel.  If  a  virtual  circuit 
exists  between  the  calling  and  called  hosts,  then  the  X.25 
channel  that  the  circuit  is  on  must  be  placed  in  the  data 
transfer  state  by  issuing  a  reset  request  packet  and  waiting 
for  receipt  of  a  reset  confirmation  packet  from  the  calling 
node.  If  no  channel  has  been  allocated  as  a  virtual  circuit 
between  the  two  hosts,  then  a  virtual  call  must  be  made. 
The  calling  host  must  send  a  call  request  packet  to  the 
calling  node.  Then  upon  receipt  of  a  call  connected  packet 
from  the  calling  node,  the  virtual  call  has  been  made  and 
the  X.25  channel  over  which  the  call  was  made  is  in  the  data 
transfer  state. 

To  clear  a  virtual  call  when  all  the  data  from  the 
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ogure  11  Exrxnte  Calling  Host  Protocol  (1)  EFD 


called  host  to  the  calling  host  has  been  transmitted,  the 
calling  host  must  send  a  clear  request  to  the  calling  node. 
The  call  must  be  cleared  and  the  channel  made  available  when 
the  calling  host  receives  a  clear  confirmation  packet  from 
the  calling  node. 

If  a  local  procedure  error  occurs,  the  virtual  calls 
and  virtual  circuits  must  be  reset  as  necessary  to  recover 
from  the  error.  The  calling  host  must  send  a  reset  request 
packet  to  the  calling  node  for  each  logical  channel  to  be 
reset.  The  channels  will  be  reset  upon  receipt  of  a  reset 
confirmation  packet  from  the  calling  node.  If  the  entire 
c a  1 1 i n g - ho s t - t o - c a  1 1 i n g - n od e  interface  is  to  be 
reinitialized  with  all  virtual  calls  being  cleared  and  all 
virtual  circuits  being  reinitialized,  then  the  calling  host 
must  send  a  restart  request  packet  to  the  calling  node.  The 
interface  must  then  be  reinitialized  upon  receipt  of  a 
restart  confirmation  packet. 

The  state  of  the  channel  must  also  be  able  to  affected 
by  the  calling  node.  If  the  calling  host  is  waiting  to 
receive  a  call  connected  packet  from  the  calling  node  and 
instead  receives  a  clear  indication  packet  from  the  calling 
node,  then  the  calling  host  must  send  a  clear  confirmation 
packet  back  to  the  calling  node  and  must  clear  the  pending 
call  request.  Also,  if  the  calling  host  receives  a  reset 
indication  packet  from  the  calling  node,  then  the  calling 
host  must  reset  the  appropriate  channel  and  send  a  reset 
confirmation  packet  back  to  the  calling  node.  Finally,  the 


calling  host  must  clear  all  virtual  calls  and  reset  all 
virtual  circuits  upon  receipt  of  a  restart  indication  packet 
and  must  respond  with  a  restart  confirmation  packet  back  to 
the  calling  node  (1.2). 

There  must  be  the  capability  from  the  calling  host  to 
control  the  flow  of  data  packets  to  the  calling  node  as  well 
as  the  capability  to  interrupt  this  flow  control  with  data 
interrupt  packets.  This  must  be  accomplished  by  the  Window 
Calling  Host  to  Called  Host  Data  Packet  (1.3)  process  and 
the  Send  Packet  to  Calling  Node  (1.4)  process.  A  windowing 
mechanism  must  be  implemented  using  the  Packet  Send  Variable 
( P ( S ) )  and  the  Packet  Receive  Variable  ( P ( R ) )  which  must 
allow  up  to  w  data  packets  that  were  transmitted  to  the 
calling  node  to  be  pending  acknowledgement  at  any  time.  W 
is  the  window  size.  The  packets  must  be  numbered 
sequentially  modulo  8  and  the  lower  window  edge  (last  packet 
acknowledged  by  the  calling  node)  must  be  updated.  This 
must  be  done  using  supervisory  packets  from  the  calling  node 
as  well  as  the  flow  control  acknowledgement  field  in  the 
transmitted  called  host  to  calling  host  data  packets  (1.3). 
The  windowed  calling  host  data  packets  must  also  carry  an 
acknowledgement  in  its  flow  control  acknowledgement  field  of 
the  last  called  host  to  calling  host  data  packet  received  by 
the  calling  host.  Since  the  host  interrupt  packets  to  the 
calling  node  are  not  windowed,  they  must  be  acknowledged  by 
an  interrupt  confirmation  packet  from  the  calling  node 
(1.4)  . 
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The  calling  host  protocol  must  also  accept  data  packets 
from  the  called  host  that  are  relayed  by  the  calling  node. 
These  packets  may  be  either  data  interrupt  packets  from  the 
called  host  or  they  may  be  data  packets  that  were  windowed 
by  the  calling  node  protocol  (1.5).  The  data  interrupt 
packets  must  be  confirmed  as  already  mentioneu  by 
transmitting  an  interrupt  confirmation  packet  back  to  the 
calling  node.  Also,  the  interrupt  data  must  be  extracted 
from  the  packet  and  sent  to  the  calling  host  (1.9,1.10). 
The  windowed  data  packets  from  the  calling  node  must  be 
reassembled  into  the  packet  sequences  that  comprised  the 
original  data  from  the  called  host.  These  packet  sequences 
must  be  assembled  by  first  buffering  all  packets  which 
indicate  that  more  packets  follow  in  the  sequence  (category 
2  packets)  until  a  packet  arrives  that  indicates  that  it  is 
the  last  packet  in  the  sequence  (category  1  packet)  .  This 
category  1  packet  must  then  trigger  the  release  of  the 
complete  packet  sequence  (1 . 6  ,1  . 7  ,1  .  R)  .  Finally,  this 
called  host  to  calling  host  complete  packet  sequence  must  be 
sent  to  the  calling  host  (1.10). 

Execute  Calling  Node  Protocol  Process.  Process  2  can 
also  be  expanded  into  a  lower-level  DFD  and  its  DFD  is  shown 
in  Figure  12.  The  level  3  packets  from  the  calling  host 
must  be  executed  and  must  result  in  packets  being  sent  out 
on  the  network  to  be  routed  to  the  called  node  as  well  as 
resulting  in  packets  being  sent  back  to  the  calling  host 
(2. 1,2. 2).  Flow  control  information  from  the  calling  host 
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level  3  packets  must  be  used  to  update  the  calling  node 
windowing  variables  (2.1). 

The  routed  called  node  packets  must  also  be  executed 
and  they  must  result  in  packets  being  sent  to  the  calling 
host  (2. 3, 2. 4).  The  windowing  variables  as  well  as  the 
calling  host  supervisory  packets  must  be  used  for  flow 
control  (2.3).  Finally,  there  must  be  a  process  to  recover 


from  a  local  procedure  error  that  might  occur  in  one  of  the 
other  processes.  This  recovery  must  be  initiated  by  either 
a  reset  indication  packet  or  a  restart  indication  packet 
sent  from  the  calling  node  to  the  calling  host  (2.5). 

An  expansion  of  the  execute  calling  host  packet  into  a 
lower-level  DFD  is  shown  in  Figure  13.  The  calling  host 
level  3  packet  must  first  be  classified  as  one  of  the  types 
of  packets  shown  in  the  DFD  (2.1.1) .  If  a  call  request 
packet  is  received,  then  an  incoming  call  packet  must  be 
generated  (2.1.2).  If  the  received  packet  is  a  calling  host 
to  called  host  data  packet,  then  its  flow  control 
acknowledgements  must  be  used  to  update  the  calling  node 
windowing  variables  (2.1.3).  Both  the  incoming  call  packet 
and  the  calling  host  to  called  host  data  packet  as  well  as  a 
calling  host  interrupt  packet  that  is  received  must  be  sent 
out  on  the  network.  The  interrupt  packet  must,  in  addition, 
be  confirmed  by  an  interrupt  confirmation  packet  from  the 
calling  node  (2.1.4).  if  a  clear  request  is  received,  then 
it  must  be  confirmed  by  a  clear  confimation  packet  from  the 
calling  node  (2.1.5).  A  node  reset  confirmation  packet  must 
be  generated  if  a  reset  request  is  received  and  the  channel 
must  be  reset  at  the  calling  node  (2.1.6).  Likewise, 
receipt  of  a  restart  request  packet  must  result  in  the 
reinitialization  of  the  calling-node-to-cal ling-host 
interface  and  the  reinitialization  must  be  confirmed  with  a 
restart  confirmation  packet  (2.1.7).  All  of  these 
confirmation  packets  must  be  sent  back  to  the  calling  host 
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and  together,  they  constitute  the  calling  node  confirmation 
packet  data  flow  shown  in  Figure  12.  A  confirmation  packet 
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from  the  calling  host  on  an  action  initiated  by  the  calling 
node  must  be  an  input  to  the  Recover  From.  Procedure  Error 


(1.5)  process.  This  is  shown  in  Figure  12  by  the  calling 
host  confirmation  packet  data  flow.  Finally,  a  calling  host 
supervisory  packet  must  be  an  input  to  the  Execute  Routed 
Called  Node  Packet  (1.3)  process  in  Figure  12. 

The  process  that  executes  routed  packets  from  the 
called  node  is  specified  in  more  detail  through  the 
lower-level  DFD  in  Figure  14.  A  routed  packet  from  the 


called  node  must  first  be  classified  as  either  a  node 
interrupt  packet,  a  call  accepted  packet,  or  a  called  host 


of. 


to  calling  host  data  packet  (2.3.1).  If  it  is  not  one  of 
these,  then  it  must  be  considered  an  invalid  packet  and 
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discarded.  A  called  node  interrupt  packet  that  is  received 
must  interrupt  the  flow  of  data  from,  the  calling  node  to  the 
calling  host.  Then,  the  data  contained  in  the  interrupt- 
packet  must  be  sent  to  the  calling  host  in  another  interrupt 
packet  from,  the  calling  node  (2.3.2).  If  the  routed  called 
node  packet  is  a  call  accepted  packet,  then  the  calling  host 
must  be  notified  of  the  virtual  call  connection  by  sending 
it  a  call  connected  packet  (2.3.3).  A  called  host  to 
calling  host  data  packet  must  be  windowed  and  sent  to  the 
calling  host.  The  windowing  is  accomplished  by  using  the 
Receive  Ready  (RR)  and  Receive  Not  Ready  ( RNR)  supervisory 
packets  from  the  calling  host  and  the  calling  node  windowing 
variables.  These  are  used  to  send  both  windowed  called  host 
to  calling  host  data  packets  as  well  as  calling  node 
supervisory  packets  to  the  calling  host  (2.3.4). 

Execute  Called  Node  Protocol  Process .  The  Execute 
Called  Node  Protocol  (4)  process  shown  in  Figure  10  is  very 
similar  to  the  execute  calling  node  protocol  process.  The 
lower-level  DFD's  for  this  process  are  shown  in  Figures  15, 
16,  and  17.  As  can  be  seen  from,  these  DFD's,  the 
requirements  for  the  Execute  Called  Node  Protocol  (4) 
process  are  almost  identical  to  those  for  the  Execute 
Calling  Node  Protocol  (2)  process.  The  major  difference  is 
in  the  handling  of  the  virtual  call  setup.  The  called  node 
must  relay  the  incoming  call  packet  to  the  called  host  and 
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Figure  15  Srv\te  Called  Node  Protocol  (4)  IK) 

then  must  relay  the  call  accepted  packet  from  the  called 
host  to  the  calling  node  (  4 . 1  .  ?  ,  4 . 3 . 3)  . 

Execute  .Stalled  Host  Pi^t^col  Process .  As  with  the 
Execute  Called  Node  Protocol  (4)  process,  the  Execute  Called 
Host  Protocol  (5)  process  also  has  an  almost  identical 
counterpart.  As  can  be  seen  from  the  lower-level  DFD  of  the 
Execute  Called  Host  Protocol  (5)  shown  in  Figure  18,  the 
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Figure  17  Exeat e  Rated  Calling  Node  Facket  (43)  EFD 


principal  difference  is  again  in  handling  the  virtual  call. 
The  Execute  Called  Host  Protocol  (5)  must  accept  a  virtual 
call  by  sending  a  call  accepted  packet  to  the  called  node 
and  it  cannot  by  definition  generate  a  call  request  (5.2). 

PX£i£££l  R£aniX£m£Hifi  .  As  with  the 
host-to-host  transfer  mechanism,  the  network  transfer 
mechanism  is  used  by  several  processes  and  is  treated  as  a 
primitive  in  the  host-to-host  protocol.  It  is  also 
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Figure  19.  Network  Protocol  Context  Diagran 
diagram  shown  in  Figure  19. 

The  network  protocol,  then,  must  transmit  packets  from 
their  source  node  to  their  destination  node.  As  can  be  seen 
from  the  Network  Protocol  Overview  DFD  in  Figure  20,  there 


Figure  2D  Network  Protocol  Overview  DFD 
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are  actually  two  processes  required  to  accomplish  the 
network  protocol.  First,  the  packet  must  be  routed  to  a 
closer  node  using  a  lookup  table  unless  it  has  reached  its 
destination  node  (1).  If  it  is  not  at  the  destination  node, 
then  the  in-transit  packet  must  be  sent  to  the  closer  node 
to  which  it  has  been  routed  (2) .  Thus,  both  a  routing 
algorithm  to  implement  the  first  process  and  a  link  transfer 
mechanism  to  implement  the  second  process  are  required  for 
the  network  protocol. 

Als.Qiii.hm  BgqQir.ements  ♦  Given  a  simple 
network  topology,  the  routing  algorithm  may  also  be  very 
simple.  There  is  only  a  requirement  for  a  look  up  table  in 
each  node  that  is  initialized  when  the  network  is  booted. 
Since  the  availability  requirement  was  only  90  percent, 
there  is  no  need  to  make  the  routing  algorithm  adajtive; 
however  error  messages  must  be  given  to  the  user  if  a  host 
active  on  the  network  cannot  be  reached.  If  a  more  complex 
topology  is  used,  then  a  distributed  adaptive  routing 
algorithm  should  be  implemented  as  recommended  by 
Ravenscroft  (Ref.  16). 

link  PXQiQQQl  EQailiX£m£HiX  .  The  X  .  ?  5  protocol 
requires  that  the  High  Level  Data  Link  Control  (HDLC)  tie 
used  for  the  level  2  or  link  protocol.  The  overview  DFD  for 
this  protocol  is  shown  in  Figure  21.  Also,  Table  7  shows 
the  process  hierarchy  for  this  set  of  DFDs .  This  protocol 
must  specify  the  mechanism  by  which  information  is  exchanged 
between  adjacent  nodes  in  the  network.  The  Execute  HDLC 


Table  7 


Link  Protocol  Process  Hierarchy 

Execute  HDLC  Protocol  at  Primary  Node 

1.1  Extract  Valid  Packet 

1.1.1  Extract  Information  Between  Flags 

1.1.2  Unstuff  Zeros 

1.1.3  Check  Length 

1.1.4  Generate  CRC  Remainder 

1.1.5  Check  FCS  Block 

1.2  Decode  Secondary  Address  and  Control  Fields 

1.3  Execute  Secondary  I-Frame  Packet 

1.3.1  Validate  I-Frame  Packet 

1.3.2  Parse  I-Frame 

1.3.3  Parse  I-Frame  Control  Field 

1.4  Execute  S-Frame  Response 

1.4.1  Parse  S-Frame  Response  Control  Field 

1.4.2  Decode  Response  Supervisory  Bits 

1.4.3  Send  Ready  Status  and  Extract  nTf.) 

1.4.4  Send  Busy  Status  and  Extract  N(R) 

1.4.5  Send  Reject  Condition  and  Extract  N(R) 

1.5  Execute  U-Frame  Response 

1.5.1  Parse  U-Frame  Response  Control  Field 

1.5.2  Decode  Response  Modifier  Bits 

1.5.3  Set  Up  Link 

1.5.4  Execute  Pending  State  Change 

1.6  Window  Primary  Information  Blocks 

1.6.1  Reset  VIS) 

1.6.2  Update  Lower  Window  Edge 

1.6.3  Poll  Secondary  for  Ready  State 

1.6.4  Place  I-Frame  in  X.25  Link 

1.6.5  Select  Packet  for  X.25  Link 

1.7  Recover  from  Procedure  Error 

1.8  Send  Packet 
Transmit  Bit  Streams 

Execute  HDLC  Protocol  at  Secondary  Mode 

3.1  Extract  Valid  Packet 

3.2  Decode  Primary  Address  and  Control  Fields 

3.3  Execute  Primary  I-Frame 

3.3.1  Validate  I-Frame  Packet 

3.3.2  Parse  I-Frame 

3.3.3  Parse  I-Frame  Control  Field 

3.4  Execute  S-Frame  Command 

3.4.1  Parse  S-Frame  Command 

3.4.2  Parse  S-Frame  Control  Field 

3.4.3  Send  Ready  Status  and  Extract  N(R) 

3.4.4  Send  Busy  Status  and  Extract  N(R) 

3.4.5  Send  Reject  Condition  and  Extract  N(R) 

3.5  Execute  U-Frame  Command 

3.5.1  Parse  U-Frame  Command  Control  Field 

3.5.2  Decode  Command  Modifier  Bits 

3.5.3  Disconnect  Link 

3.5.4  Set  Up  Link 

3.6  Window  Secondary  Information  Blocks 

3.6.1  Reset  V(S1 

3.6.2  Update  Lower  Window  Edge 

3.6.3  Set  Response  Final  Bit 

3.6.4  Place  I-Frame  in  X.25  Link 

3.6.5  Select  Packet  for  X.25  Link 

3.6.6  Respond  to  Status  Request 

3.7  Request  Recovery  from  Procedure  Error 

3 . 8  Send  Packet 


Protocol  at  Primary  Node  (1)  process  and  the  Execute  HDLC 
Protocol  at  Secondary  Node  (3)  process  differ  in  that  the 
former  node  must  have  the  responsibility  for  resetting  the 
channel  as  well  as  polling  the  status  of  the  latter  node. 
However,  other  than  these  additional  responsibilities,  the 
processes  are  very  similar.  The  Transmit  Bit  Streams  (2) 
process  is  performed  by  the  physical  protocol  and  the 
transmission  medium  and  so  its  requirements  are  analyzed  in 
a  later  section.  First,  the  Execute  HDLC  Protocol  at 
Primary  Node  (1)  will  be  analyzed. 

Execute  HDLC  Protocol  a£  Primary  Node.  An  expanded 
DFD  of  this  process  is  shown  in  Figure  22.  There  must  be  an 
incoming  bit  stream  from  the  secondary  node  and  an  outgoing 
bit  stream  to  that  node  since  HDLC  is  a  bit-oriented 
protocol.  This  satisfies  the  transparency  requirement  that 
was  specified  to  allow  the  transfer  of  binary  files.  The 
node  must  supply  level  3  packets  to  the  Execute  HDLC 
Protocol  at  Primary  Node  (1)  process  through  the  routing 
algorithm  and  the  interface  with  the  host-to~host  protocol. 
This  process  views  the  level  3  packets  strictly  as 
information  blocks  to  be  transmitted  and  thus  the  coupling 
between  level  2  and  level  3  is  minimized.  This  allows  the 
protocol  flexibility  requirement  specified  in  Chapter  IT  to 
be  met  much  more  easily.  Also,  transmitted  information 
blocks  from  the  secondary  node  must  be  able  to  be  extracted 
from  the  incoming  bit  stream  and  supplied  to  the  routing 
algorithm  and  host-to-host  transfer  mechanism. 
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The  incoming  bit  stream  must  be  monitored  by  the 
Extract  Valid  Packet  (1.1)  process  and  valid  level  2  packets 
extracted  from  the  stream.  These  level  2  packets  must  then 
be  classified  by  their  address  and  control  fields  as  either 
information  (I-frame)  packets,  supervisory  (S-frame) 
response  packets,  or  unnumbered  (U-frame)  response  packets. 
The  transmitted  information  block  must  be  extracted  from  the 
I-frame  packet  and  the  packet  sequence  information  in  each 
of  the  types  of  packets  must  be  provided  to  the  windowing 
process  (1.3)  .  A  windowing  mechanism  very  similar  to  that 
used  in  the  level  3  protocol  must  be  used  by  the  Execute 
HDLC  Protocol  at  Primary  Mode  (1)  process  to  achieve  flow 
control  over  the  link.  The  Window  Primary  Information 
Blocks  (1.6)  process  must  use  the  packet  sequence 
information  V(S)  to  insure  that  no  more  than  k  blocks  are 
pending  acknowledgement  at  any  time  where  k  is  the  window 
size.  The  windowed  information  blocks  as  well  as  the 
command  and  response  packet  replies  must  be  assembled  into 
level  2  packets  to  be  sent  to  the  secondary  node.  Local 
procedure  errors  due  to  invalid  length  packets,  invalid 
packet  types,  and  out  of  sequence  I-frames  must  be  recovered 
from  by  generating  a  set  asynchronous  balanced  mode  (SARM) 
command.  This  command  initiates  the  resetting  of  the  link 
in  both  directions  (1.7).  Finally,  the  level  2  packet  must 
be  sent  out  of  the  node  in  the  outgoing  bit  stream  by 
inserting  the  packet  between  two  flag  characters  (l.R). 

Extract  Valid  Packet .  The  Extract  Valid  Packet  (1.1) 
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process  is  expanded  into  a  lower-level  DFD  in  Figure  23. 
The  incoming  bit  stream  must  first  be  monitored  for  the  flag 
sequence  of  bits  that  signifies  the  start  or  end  of  a 
packet.  Once  this  sequence  is  detected,  all  information 
between  it  and  the  next  flag  must  be  extracted  and  passed  as 
a  level  2  packet  to  the  Unstuff  Zeros  (1.1.2)  process. 
However,  if  an  abort  sequence  of  seven  contiguous  ones  is 
detected  or  an  idle  channel  state  is  indicated  by  fifteen 
contiguous  ones,  then  the  packet  being  extracted  must  be 
discarded  (1.1.1).  The  Unstuff  Zeros  (1.1.2)  process  must 
remove  zero  bits  that  were  stuffed  in  the  packet  to  prevent 
the  bit  patterns  in  the  packet  from  appearing  as  the  flag 
sequence.  The  unstuffed  packet  must  be  checked  for  valid 
length  and  packets  of  invalid  length  must  also  be  discarded 
(1.1.3)  .  Finally,  the  valid  length  packet  must  be  checked 
for  bit  errors  by  regenerating  the  cyclic  redundancy  check 
(CRC)  remainder  and  comparing  it  to  the  frame  checking 
sequence  (FCS)  in  the  packet.  If  they  match,  then  the 
packet  must  be  valid.  Otherwise,  the  packet  must  be 
discarded  (1 .1 .4 ,1 .1 .5)  . 

Execute  I-Frame  Packet .  As  shown  in  the  lower-level 
DFD  for  this  process  in  Figure  24,  the  I-frame  packet  must 
first  be  validated  by  comparing  the  next  packet  expected 
number  N(P.)  of  the  I-frame  to  the  primary  receive  state 
variable  V(P)  .  If  they  do  not  match  then  the  I-frame  must 
be  considered  invalid  (1.3.1).  Otherwise,  the  valid  I-frame 
packet  must  be  parsed  and  the  control  field  separated  from. 


Prinury_V(R) 


Figjrre  24  Execute  Secondary  I-Firrc  Fhdcet  (1.3)  HD 

the  transmitted  information  block  (1.3.?).  The  control 
field  must  then  be  parsed  further  to  extract  N(R)  and  the 
packet  sequence  number  N(S).  The  transmitted  information 
block  must  be  provided  to  the  node  as  a  level  3  packet  and 
N(R)  and  N ( S )  must  be  used  to  provide  packet  sequence 
information  to  the  windowing  mechanism  (1.3.3). 

-Execute  R£ span S£  .  The  Execute  S-Frame 
Response  (1.4)  process  lower-level  DFD  is  shown  in  Figure 
25.  The  S-frame  must  first  be  parsed  to  extract  the 
response  supervisory  function  bits  and  the  final  bit 
(1.4.1) .  If  the  final  bit  is  set,  then  the  response  must  be 
interpreted  as  the  reply  to  the  last  command  sent  out  by  the 
process  with  the  poll  bit  set.  The  supervisory  modifier 


bits  must  be  classified  as  either  a  Receive  Ready  (F:R) 
response,  a  Receive  Not  Feady  (FNR)  response,  or  a  Reject 


figure  25  Execute  S-Fttme  Response  (J  .4)  ITD 


(REJ)  response  (1.4.2).  If  the  S-frame  response  is  an  RR 
response,  then  the  ready  indication  must  be  sent  to  the 
Window  Primary  Information  Rlocks  (1  (1.4. 3). 6)  process. 
Also,  the  N ( R )  of  the  RR  response  must  be  used  to  update 
V ( R )  which  stores  the  sequence  number  of  the  next  I-frame 
expected  from  the  secondary  node.  If  the  S-frame  response 
is  an  response,  then  the  busy  status  must  be  sent  to  the 
windowing  process  and  N  (  R )  used  to  update  V(R)  (1.4.4). 
Finally,  a  REJ  response  must  result  in  the  N(R)  of  the  REJ 
response  updating  V(R)  and  the  windowing  process  receiving  a 
reject  exception  condition  (1.4.5). 

£i££Ut£  UrFx5ID£  R£SPPR££  .  The  Execute  U-Frame 
Response  (1.5)  process  can  also  be  expanded  further  as  shown 
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in  Figure  2  6.  The  U -frame  response,  like  the  S-frame 


response,  must  first  be  parsed  to  extract  the  final  bit  and 
the  modifier  bits  (1.5.1).  The  final  bit  must  be  processed 
as  it  was  for  the  S-frame  response  and  the  response  modifier 
bits  must  be  decoded  and  the  U-frame  response  classified  as 
either  a  disconnected  mode  (DM)  response,  an  unnumbered  (UA) 
response,  or  a  command  (frame)  reject  (CMDR(FRMR))  response 
(1.5.2) .  A  DM  response  or  a  CMDR(FRMR)  response  from  the 
secondary  node  must  result  in  an  SABM  command  being  sent  to 
the  windowing  process  to  initiate  setting  up  the  link 
between  the  primary  and  secondary  nodes.  Also,  this  pending 
link  setup  must  be  stored  in  the  pending  state  change 
variable  (1.5.3).  If  the  U-frame  resonse  is  a  UA  response, 
then  the  pending  state  change  variable  must  be  accessed  to 
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determine  if  a  link  setup  or  disconnect  is  pending.  If  so, 
the  state  must  be  changed  to  the  pending  state  and  the 
pending  state  change  variable  cleared  (1.5.4). 

Window  Primary  Information  Blocks .  As  can  be  seen  in 
Figure  27,  this  process  must  exercise  overall  control  over 
both  directions  of  the  link  transmission.  A  rejection 
exception  condition  must  be  cleared  by  resetting  the  primary 
send  state  variable  V(S)  to  the  M(R)  supplied  from,  the 
Execute  S-Frame  Response  (1.4)  process  and  by  sending  a 
reject  ready  indication  to  the  Place  I-Frame  in  X.25  Link 
Queue.  This  is  done  by  the  Reset  V(S)  process  (1.6.]). 
Trregardless  of  whether  the  N(R)  came  from  an  I-frame,  an  RR 
command,  an  RNR  command,  or  a  REJ  command,  it  must  be  used 
to  update  the  lower  window  edge.  This  updated  lower  window 
edge  must  then  be  used  to  place  I-frames  in  the  X.25  link 
queue  (1.6.2).  The  busy  and  ready  indications  must  be  used 
to  place  the  X.25  link  in  the  ready  condition  as  soon  as 
possible,  if  it  is  not  in  that  state  already  (1.6.3).  This 
is  done  by  generating  an  RR  command  to  poll  the  secondary 
node  repeatedly  until  it  indicates  that  it  is  in  the  ready 
state.  When  the  1  ink  status  input,  the  reject  ready 
indication,  or  the  ready  indication  indicates  that  the 
secondary  node  is  in  the  ready  state,  then  I-frames  must  be 
placed  in  the  X.25  link  queue  until  V(S)  is  one  less  than 
the  updated  lower  window  edge  (modulo  k)  (1.6.4).  Finally, 
the  Select  Packet  for  X.25  Link  (1.6.5)  process  must  select 
the  level  2  packet  to  be  sent  next  by  servicing  the  I-frame 


Figure  27  VLuJcw  Priirary  Infonvaticn  Blocks  (1.6)  EFD 


queue  but  giving  priority  to  the  SABM  command,  RR  command, 
or  DISC  command  if  one  is  waiting  to  be  transmitted. 

HHLC  gt;  £e conda r y  Node .  As  can  be 


seen  from  Figure  28,  this  process  is  very  similar  to  the 
Execute  HDLC  Protocol  at  Primary  Node  (1)  process.  There 
are,  however,  some  major  differences.  The  valid  primary 
packet  may  be  either  an  I-frame,  an  S-frame  command,  or  a 
U-frame  command  (3.2) .  Thus,  the  primary  node  must  send 
S-frame  and  U-frame  commands  to  the  secondary  node  while  the 
secondary  node  can  only  send  back  S-frame  and  U-frame 
responses.  Also,  the  secondary  node  must  request  recovery 
from  procedure  errors  by  sending  CMDR(FRMR)  responses  to  the 
primary  node  (3.7).  Finally,  the  primary  I-frame  may  have  a 
node  status  polling  request  that  must  be  answered  with 
either  an  I-frame  or  an  S-frame  response  (3.3,3.^). 

Execute  Primary  I-Frame.  This  process  is  similar  to 
the  Execute  Secondary  I-Frame  (1.3)  process  but  differs 
slightly.  The  lower-level  DFD  of  the  Execute  Primary 
I-Frame  (3.3)  process  in  Figure  29  shows  that  the  poll  bit 
is  extracted  from  the  I-frame  rather  than  the  final  bit 
(3.3.2).  Other  than  this  slight  difference  the  I-frames  are 
processed  almost  identically  by  the  primary  and  secondary 
nodes . 

Execute  S-Frame  Command .  The  lower-level  DFD  for  the 
Execute  E-Frame  Command  (3.4)  process  is  shown  in  Figure 
30.  It  is  also  identical  to  its  counterpart  with  the 
exception  of  the  poll  bit  (3.4.1). 

Execute  U-Frame  Command .  The  Execute  U-Frame  Command 
(3.5)  process  is  quite  different  from  its  counterpart  in  the 
primary  node.  As  shown  in  Figure  31,  the  U-frame  command 
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Figure  28.  B^cute  H3X  Protocol  at  Secondary  Node  0)  ZH> 


can  be  either  a  disconnect  (DISC)  command  or  an  SABM  command  , 

transmitted  from  the  primary  node  (3.5.2).  The  DISC  command 

must  result  in  the  secondary  node  entering  the  disconnected  ] 

state  and  generating  a  UA  response  to  be  sent  to  the  primary 

node.  If  the  node  was  already  disconnected,  then  a  DM 

response  must  be  generated  instead  (3.5.3).  The  transmitted 

SABM  command  must  result  in  the  link  being  reinitialized 

with  V ( R )  and  V(S)  set  to  zero.  Moreover,  a  UA  response 

must  be  generated  for  this  command  (3.5.4).  j 

Window  Secondary  Information  Blocks.  The  lower-level  | 

DFD  of  this  process  is  shown  in  Figure  32.  In  addition  to 

the  processes  required  in  the  Window  Primary  Information  ij 

1 

Blocks  (1.6)  ,  this  process  also  must  insure  that  responses  | 
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are  generated  to  all  commands  received  from  the  primary  node 
and  that  in  those  responses,  the  final  bit  is  set 
(3. 6. 3, 3. 6. 6)  . 

Physical  Protocol  Requi rements .  The  X.2  5  protocol 
requires  that  the  RS-449  interface  standard  be  used  to 
implement  the  physical  level  protocol.  However,  levels  2 
and  3  do  not  require  that  a  certain  physical  level  protocol 
be  used.  Thus,  this  requirement  for  the  RS-449  interface 
was  not  considered  binding.  There  were,  then,  two  principal 
requirements  for  the  physical  level  protocol.  It  had  to  be 
a  widely  recognized  standard  to  minimize  the  difficulty  in 
adding  new  hosts  to  DELNET  and  it  had  to  be  compatible  with 
the  transmission  medium  selected  and  the  distances  of 
transmission  required.  The  distance  from  the  hosts  to  their 
entry  nodes  should  not  exceed  75  feet  given  the  present 
available  space  in  the  Digital  Engineering  Laboratory. 
Thus,  if  these  requirements  could  be  met  then  the  Transmit 
Bits  (2)  process  in  the  link  level  protocol  could  be 
performed. 

-Summary 

This  chapter  has  refined  the  hardware  specifications 
and  addressed  the  software  specifications  for  DELNET  in 
detail.  The  software  specification  was  lengthy,  and  yet, 
because  of  the  partitioning  and  levels  of  abstraction  made 
possible  through  the  use  of  Structured  Analysis,  it  was 
fairly  easy  to  comprehend.  The  data  dictionary  contains 
even  more  information  on  these  specifications  and  for  that 
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reason  is  included  as  Appendix  C.  These  requirements  formed 
the  basic  foundation  for  the  overall  structural  design  of 
the  DELNET  software  described  in  Chapter  IV. 


IV.  Design  q£  DELNET 
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I  troduction 

The  previous  chapters  determined  the  user  functional 
requirements  and  translated  them  into  a  detailed  set  of 
hardware  requirements  as  well  as  a  structured  software 
specification.  In  this  chapter,  the  hardware  requirements 
are  employed  along  with  supporting  background  information  to 
develop  the  hardware  design.  The  software  for  DELNET  is 
also  designed  using  Yourdon  and  Constantine's  structured 
design  techniques  to  translate  the  structured  specification 
into  the  module  structure  charts  found  in  Appendix  D. 
Finally,  the  software  modules  are  allocated  to  specific 
processors  in  DELNET. 

Hardware  Design 

Topology.  Although  there  was  a  requirement  that  the 
topology  be  able  to  be  easily  modified,  there  was  still  a 
need  for  an  initial  DET.NET  topology.  The  topology  shown  in 
Figure33  was  chosen  for  several  reasons.  The  basic  loop 
architecture  of  the  nodes  allows  the  routing  algorithm  to  be 
simple  since  a  message  has  only  two  possible  paths  to  its 
destination  node.  This  decreases  the  development  time  of 
DFI.NET  and  allows  it  to  be  operational  while  a  more 
sophisticated  routing  algorithm  is  being  developed  to  handle- 
more  complex  topologies.  Also,  the  loop  network  has  only 
one  more  link  between  nodes  than  a  minimum  spanning  tree. 
This  can  be  seen  by  deleting  one  link  from  the  loop 
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Figure  33.  Basic  lord'  Trynlcgy 


architecture.  The  network  in  this  case  degen  e  r  c\  tes  to  a 
linear  connection.  Since  no  more  links  can  he  removed  from 
the  retwork  and  leave  it  connected,  this  constitutes  a 
minimum  spanning  tree.  This  makes  the  loop  architecture 
cost-effective.  Since  adding  another  node  simply  requires 
breaking  one  connection  and  adding  two  new  ones,  the  loop 
network  is  easy  to  expand.  It  is  these  advantages  that  make 


the  loop  network  preferable  in  general  for  local  networks 
and  very  useful  in  the  case  of  DELNET  in  particular  (Ref. 
10:  75).  There  are  disadvantages,  however,  to  the  loop 
topology.  The  reliability  decreases  as  the  number  of  nodes 
on  the  network  increases.  This  is  a  direct  consequence  of 
the  near  minimum  number  of  links  in  the  network.  Also,  the 
response  time  will  increase  as  the  number  of  nodes  increases 
since  each  node  that  a  message  must  pass  through  adds  a 
delay  to  the  transit  time.  Since  the  initial  number  of 
nodes  on  the  network  will  be  small  and  since  the 
availability  was  only  90  percent,  these  disadvantages  do  not 
pose  a  problem  at  present. 

The  star  topology  connecting  the  hosts  to  the  node  was 
chosen  for  three  reasons.  First,  it  minimizes  the  loop 
topology's  disadvantages  by  decreasing  the  number  of  nodes 
in  the  network.  Also,  by  allowing  one  node  to  interface 
several  hosts  to  DELNET,  it  is  cost-effective  since  the  cost 
of  the  nodes  can  be  substantial.  This  will  be  seen  in  a 
following  section  addressing  the  node  design.  In  addition, 
the  star  topology  makes  it  practical  to  interface  small 
inexpensive  computers  such  as  the  F  &  r  Instruments 
Mini- Micro  Designer  (MMD-1)  to  the  network  (Ref.  11: 
Chapter  IV)  .  This  is  true  even  though  the  computers'  costs 
might  only  be  a  fraction  of  the  the  node's  costs.  Another 
advantage  is,  that  the  hosts  that  will  interact  th<  mst  with 
each  other  can  be  grouped  j  t  the  sari  node.  In  t  h  i  r 
configuration,  much  of  the  traffic  need  only  nass 
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its  entry  node  to  the  network.  This  decreases  the  average 
response  time  on  DELNET  and  decreases  the  amount  of  traffic 
transmitted  between  nodes.  However,  reliability  from  the 
host's  perspective  is  decreased  since  the  failure  of  a  node 
can  cause  several  hosts  to  lose  access  to  the  network. 
Also,  there  must  be  a  greater  transmission  rate  between 
nodes  than  that  between  the  hosts  and  the  nodes.  This  is  to 
keep  the  nodes  from  acting  as  bottlenecks  and  thereby 
decreasing  throughput  to  an  unacceptable  level. 

Hosts.  Three  hosts  were  chosen  for  the  initial 
network  configuration.  This  number  represents  the  minimum 
number  of  hosts  that  would  exercise  the  protocols 
sufficiently.  The  VAX-11/780  was  chosen  because  it  is  the 
most  powerful  and  sophisticated  of  the  minicomputers  in  the 
Digital  Engineering  Laboratory.  It  also  has  the  capability 
to  transfers  files  to  and  from  the  CYBER  750  and  thus  helps 
to  partially  fulfill  the  user  requirement  for  access  to  that 
host.  The  Intel  Series  II  MDS  was  chosen  to  represent  the 
other  end  of  the  spectrum  since  it  is  an  8080-based 
microcomputer  and  has  a  high  rate  of  usage.  Also,  a 
distributed  database  system  has  been  designed  for  this 
computer  that  should  aid  efforts  in  implementing  a 
distributed  database  system  on  DELNET.  The  third  host 
chosen  was  the  Data  General  Nova.  This  computer  has  a  high 
usage  rate  and  is  already  linked  through  a  shared  disk  drive 
to  the  Data  General  Eclipse.  It  is  also  linked  to  the  Cyber 


750  mainframe  computer  through  a  communications  protocol  and 


a  300  baud  telephone  line.  Thus,  the  Nova  will  allow  the 
other  hosts  on  DELNET  to  have  indirect  access  to  the  Cyber 
750  and  the  computational  power  of  the  Eclipse. 

Nodes .  The  first  possibilities  examined  to  perform 
the  function  of  the  nodes  on  DELNET  were  existing  local 
network  software  packages  that  might  be  procured  to 
interface  the  hosts  selected.  These  were  rejected  for  two 
principal  reasons.  The  commercially  available  networks 
offered  no  flexibility  to  the  protocols  they  employed  and 
would  have  been  very  difficult  to  modify.  This  is 
especially  true  since  these  packages  do  not  usually  include 
the  source  code.  The  other  deterrent  was  the  high  cost  of 
these  network  packages.  For  at  least  one  of  the  networks, 
the  cost  of  including  many  of  the  computers  in  the  Digital 
Engineering  Laboratory  was  higher  than  the  cost  of  the 
computers  themselves. 

A  Universal  Network  Interface  Device  (UNID)  developed 
by  the  Digital  Engineering  Laboratory  was  also  studied  for 
possible  use  as  the  node  in  DELNET  (Refs.  4,18).  The  UNID 
offered  several  advantages.  Since  it  was  developed  as  a 
series  of  Digital  Engineering  Laboratory  research  projects, 
complete  documentation  on  the  development  and  design  of  the 
UNID  is  available.  Thus,  any  required  modification  to  the 
UNID's  hardware  would  be  facilitated.  The  UNID  was 
developed  for  a  multi-loop  network  but  can  be  used  in  all 
topologies  except  a  bus  architecture.  So,  the  requirement 
for  flexibility  in  the  topology  could  be  satisfied.  In 
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addition,  the  use  of  two  Z-80A  microprocessors  in  each  UNID 
allows  parallel  processing  to  take  place  and  minimizes  the 
time  that  the  packets  must  spend  being  processed  by  the 
nodes.  The  availability  of  a  higher  level  language,  PL/Z, 
and  a  software  development  system  that  has  been  interfaced 
to  the  UNID  is  also  a  significant  advantage.  Finally,  using 
the  UNID  in  DELNET  also  would  satisfy  an  existing 
requirement  to  test  the  UNID  in  an  operational  environment. 
The  major  disadvantage  to  the  UNID  was  its  fairly  high  cost 
(approximately  three  thousand  dollars)  which  limits  the 
number  of  UNlDs  that  can  be  procured  initially  for  DELNET. 
Because  the  advantages  of  the  UNID  greatly  outweighed  the 
disadvantage  associated  with  its  cost,  the  UNID  was  selected 
as  the  node  for  DELNET. 

One  UNID  has  been  built  and  has  been  tested  using  some 
basic  software  routines  (Ref.  4).  Because  this  UNID  was 
still  in  the  prototype  stage,  only  enough  parts  for  one 
additional  UNID  were  ordered.  The  two  UNIDs  will  allow 
eight  hosts  to  be  included  in  DELNET  and  so  the  three  hosts 
in  the  initial  configuration  can  be  easily  accomodated. 

Transmission  Medium.  The  requirement  that  one  link 
in  DELNET  use  fiber  optics  was  met  by  procuring  a  fiber 
optic  data  link  to  connect  the  two  UNIDs.  This  link  was 
chosen  to  be  implemented  using  fiber  optics  due  to  its 
requirement  for  a  high  transmission  rate  (56  Kbs)  and  its 
length  (120  ft).  The  links  between  the  UNIDs  and  the  hosts 
will  be  implemented  using  twisted  pair  since  the 
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transmission  rate  is  limited  to  19.2  Kbaud  by  the  serial 
ports  on  the  hosts  and  the  distances  between  the  hosts  and 
the  UNIDs  are  less  than  75  feet.  Since  no  problems  have 
been  experienced  in  the  Digital  Engineering  Laboratory  with 
links  of  this  distance,  this  lowest-cost  option  was 
selected.  As  additional  UNIDs  are  added  to  DELNET,  these 
will  be  interconnected  using  shielded  twisted  pair.  Other 
mediums  considered  for  the  links  included  coaxial  cable, 
broadband  coax,  and  ribbon  cable.  The  coaxial  cable  would 
allow  higher  transmission  rates  but  was  not  considered 
justified  by  the  throughput  and  response  time  requirements. 
Very  high  transmission  rates  can  be  obtained  using  broadband 
coax  and  yet  the  modems  required  for  the  interface  to  the 
medium  are  very  costly.  Broadband  coax  is,  however,  an 
attractive  alternative  for  local  networks  when  very  high 
transmission  rates  are  desired  (Ref.  8).  Finally,  ribbon 
cable  was  rejected  due  to  its  low  noise  tolerance  and 
because  a  bit-serial  protocol  was  to  be  employed.  The  total 
hardware  design  is  shown  in  Figure  34. 

Software  Design 

InilLjQdilStiOIl .  The  design  of  the  software  was 
accomplished  using  structured  design  techniques  proposed  by 
Yourdon  and  Constantine.  Two  principal  methods  were  used  to 
translate  the  structured  specification  into  module  structure 
charts,  transform  analysis  and  transaction  analysis.  These 
techniques  were  chosen  due  to  their  direct  correspondence  to 
the  DFDs  specified  in  Chapter  3. 
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Figure  34.  Initial  Network  Qnfiguratian 

Transform  analysis  is  used  to  translate  a  DFD  into 
three  sets  of  modules.  The  first  set  of  modules  gets  data 
from  the  source.  The  data  is  transformed  into  the  output  by 
the  second  set  and  the  third  set  outputs  the  data  to  the 
sink.  To  partition  the  DFD  into  the  three  sets  of  modules, 
the  DFD  is  divided  into  an  afferent  branch,  a  transform 
section,  and  an  efferent  branch.  This  is  done  by  tracing 
the  input  from  the  source  to  the  furthest  data  flow  where  it 
is  still  recognizable  as  an  input.  Likewise,  the  output  is 
traced  backwards  from  the  sink  to  the  first  data  flow  where 
it  is  recognizable  as  an  output.  These  two  data  flows  then 
are  used  as  the  boundaries  between  the  three  sections  of  the 
DFD. 

For  the  first  set  of  modules,  the  structure  is  derived 
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by  making  an  afferent  module  for  each  data  flow  and  a 
transform  module  for  each  process.  This  is  illustrated  in 


Figire  35.  Factoring  the  Afferent  Branch 


Figure  35.  For  the  second  set  of  modules,  the  first  module  is 
factored  into  subordinate  transform  modules  that  perform  the 
functions  stated  by  the  process  names.  An  example  of  this 
is  shown  in  Figure36.  The  structure  for  the  last  set  of 
modules  is  designed  similarly  to  the  set  of  afferent 
modules.  As  shown  in  Figure  37,  the  efferent  module  has 
subordinate  to  it  another  efferent  module  and  a  transform 
module  that  relates  the  two  data  flows  specified  by  the 
efferent  modules.  A  complete  description  of  transform 
analysis  is  given  in  Yourdon  and  Constantine's  book. 
Structured  Design  (Ref.  22:  187-222) .  The  module  structure 
chart  showing  all  three  sets  of  modules  is  shown  in  Figure 
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figure  36.  Factcrirg  the  Transfam  Section 


38.  This  technique  was  used  throughout  the  module  structure 
design  phase.  An  example  of  this  technique  being  used  in 
the  DELNET  design  is  shown  in  Figure39  for  the  file  transfer 
protocol . 

The  other  technique  that  was  used  a  great  deal  was 
transaction  analysis  (Ref.  22:  223-229).  This  technique  is 
particularly  useful  for  translating  DFDs  with  processes  that 
classify  an  input  as  one  of  a  number  of  outputs.  Using 
transaction  analysis,  a  DFD  like  that  shown  in  Figure  40(a) 
may  be  translated  into  a  module  structure  chart  like  that  in 
Figure40(b).  The  module  structure  chart  for  the  help  user 
protocol  is  shown  in  Figure  41  as  an  example  of  this 
technique. 

Allocation  Ql  Software  Modules 
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figure  37.  Factoring  the  Efferait  Brandi 


A  complete  set  of  module  structure  charts  can  be  found 
in  Appendix  D  for  the  system  software  design.  However, 
there  are  some  design  decisions  that  were  made  that  are  not 
obvious  from  the  module  structure  charts.  These  decisions 
include  the  allocation  of  the  software  modules  to  the 
various  processors  on  DELNET  and  also  the  allocation  of  some 
of  the  lowest  level  module  functions  to  hardware  devices. 
These  allocations  are  discussed  in  the  following 
paragraphs. 

iiisil~L.6V.6j.  PCQ.tOQgl  Design «  The  network  operating 
system  (NOS)  is  obviously  distributed  over  all  the 
processors  in  DELNET.  However,  an  attempt  was  made  to 
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centralize  as  many  functions  that  were  not  host-specific  in 
one  host  for  two  reasons.  The  configuration  control  and 
ease  of  modification  are  both  enhanced  if  only  one  copy  of 
the  module  exists  at  an  NOS  host.  If  each  host  has  a  copy 
of  each  module,  then  a  change  to  the  network  command 
language  entails  changing  the  software  in  every  host.  Also, 
the  presence  of  modules  in  every  host  performing  identical 
functions  unnecessarily  uses  storage  space  on  each  host. 
There  are  some  disadvantages  to  centralizing  as  much  of  the 
NOS  as  possible  on  one  host,  though.  If  the  NOS  host  fails, 
then  the’network  is  not  operational.  Also,  more  traffic 
must  be  routed  to  the  NOS  host  than  would  be  the  case  if 
each  host  processed  the  network  commands.  Table  8  lists 
those  modules  that  are  present  in  each  host  and  Table  9 
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Table  8 


High-Level  Protocol  Modules  Present  at  Each  Host 

Get  User  Command 

Put  User  Response 

Execute  User  Command 

Execute  Local  Command 

Route  Local  Command 

Execute  Routed  Local  Command 

Route  Local  Response 

Execute  Network  Command 

Send  Command  to  Host  with  NOS 

Send  Response  to  User 

Get  Network-Structured  File 

Get  Host-Structured  File 

Restructure  File  for  Network 

Transmit  Network-Structured  File 

Restructure  File  for  Host 

Store  Host-Structured  File 

Log  User  into  Network 

Log  User  out  of  Network 

lists  those  modules  that  are  located  only  in  the  NOS  host. 
Obviously,  most  of  the  modules  are  too  host-specific  to  be 
located  in  the  NOS  host,  however  those  modules  most  likely 
to  be  changed  were  able  to  be  centralized  there. 

Lower-level  Protocol  Design.  The  availability  of  the 


Table  9 


Additional  High-Level  Protocol  Modules 
Present  at  NOS  Host 

Execute  Transmitted  Network  Command 
Transfer  File 

Transmit  Get-File  Command  to  Source  Host 

Control  Session 

Get  List  of  File  Transfers 

Help  User 

Provide  General  Network  Introduction 
Provide  Explanation  of  File  Transfer  Command 
Provide  List  of  Active  Hosts  and  Devices 
Provide  Explanation  of  Session  Control  Commands 


two  processors  in  the  UNID  allowed  almost  all  the 
host-to-host,  network,  and  link  level  protocol  modules  to  be 
allocated  to  the  nodes.  This,  however,  generated  an 
additional  requirement  for  the  host-to-node  interface.  A 
virtual  terminal  protocol  was  required  to  make  the  node 
appear  as  a  terminal  to  its  hosts.  Thus,  the  overall 
allocation  of  modules  between  the  processors  was  as  shown  in 
Figure  42  . 

By  locating  the  calling  host  protocol  in  the  local  side 
of  the  UNID,  the  amount  of  work  necessary  to  implement  this 
protocol  is  decreased  significantly.  This  is  because  the 
modules  are  not  host-specific  and  need  only  be  written 
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once.  The  virtual  terminal  protocol  is  the  only 
host -spec i f i c  interfacing  requirement  and  this  can  be 
implemented  with  an  interrupt-driven  routine  on  single-user 
hosts  and  by  sending  the  necessary  operating  system  commands 
on  a  multi-user  system  like  the  VAX-11/780  to  create  a  file 
from  a  terminal  and  to  output  a  file  to  a  terminal. 

Another  advantage  to  allocating  the  calling  host 
protocol  to  the  local  side  of  the  UNID  is  that  the  calling 
host  and  the  calling  node  protocols  can  communicate  through 
32  Kbytes  of  shared  memory  in  the  UNID.  There  are  also  32 
Kbytes  of  memory  for  each  processor  that  enables  all 
buffering  and  packet  assembly  to  be  done  in  the  node.  The 
shared  memory  is  much  more  reliable  and  so  this  is  also  an 
advantage. 

The  same  advantages  hold  for  allocating  the  called  host 
protocol  also  to  the  local  side  of  the  UNID.  In  addition, 
because  the  calling  host  and  called  host  protocols  are  so 
similar,  most  of  the  modules  can  be  shared  by  both. 
Likewise,  the  calling  node  and  called  node  protocols  can 
also  share  most  modules  between  them. 

The  routing  algorithm  module  must  be  allocated  to  the 
network  side  of  the  UNID  as  must  be  the  link  protocol 
modules.  However,  almost  all  of  the  Extract  Valid  Packet 
Module  and  Insert  Packet  in  the  Bit  Stream  Module  can  be 
accomplished  by  the  Z  -  80  Serial  Input  Output  (SIO) 
integrated  circuit.  This  SIO  is  programmable  and  ran 
accomplish  many  of  the  functions  such  as  CRC  checking  at  a 
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much  faster  rate  than  could  be  done  by  the  network  processor 
(Ref.  23). 

Summary 

This  chapter  has  translated  the  hardware  and  software 
requirements  into  a  system  design.  The  hardware  design 
specifies  the  topology  to  be  used,  the  hosts  to  be  included, 
the  specific  node  to  use,  and  the  transmission  mediums  to  be 
used  for  each  of  the  links.  Each  of  these  design  decisions 
is  based  upon  the  requirements  analysis  and  supported  by 
background  data  gained  from  researching  the  various  design 
options.  The  software  design  is  based  upon  the  structured 
specification  and  was  derived  primarily  using  transform 
analysis  and  transaction  analysis.  These  techniques  are 
very  briefly  described  and  the  module  structure  charts  are 
included  in  Appendix  D.  Finally,  the  software  modules  were 
allocated  to  the  processors  in  the  network  and  this 
allocation  design  was  supported  by  an  analysis  of  the  impact 
of  each  allocation  decision. 
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1.  Implementation  and  Testing 
NelttPdS  Command  Language  Interpreter 

Introduction 

The  modules  in  the  NOS  host  that  interpret  the  network 
commands  entered  by  the  user  have  been  implemented.  In 
addition,  the  "help"  user  protocol  was  implemented 
completely.  The  unique  factors  that  impacted  this 
implementation  are  discussed  in  this  chapter  as  are  the 
basic  principles  used  in  implementing  the  modules.  Also, 
the  testing  procedures  that  were  employed  to  verify  the 
modules  are  summarized.  Finally,  the  testing  results  are 
stated. 

Implementation 

One  of  the  first  challenges  in  the  implementation  phase 
was  to  devise  a  log-in  procedure  to  the  network  that  would 
not  be  host-specific.  The  word,  "NETWORK,"  was  chosen  as 
the  character  string  to  be  used  for  two  reasons.  It  does 
not  contain  any  special  characters  that  might  be 
misinterpreted  by  the  host's  operating  system.  Also,  this 
word  is  easy  for  the  user  to  remember  and  so  it  improves  the 
man-machine  interface.  This  module  was  implemented  on  the 
VAX-11/780  by  placing  a  symbol  assignment  in  the  operating 
system  routine  that  logs  in  the  user.  This  symbol 
assignment  equates  the  character  string  "NETWORK"  to  a 
command  procedure  file  call.  Thus,  typing  in  "NETWORK" 
causes  a  command  procedure  file  to  be  executed  which  then 
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activates  the  main  network  module  that  interprets  the 
network  commands.  Although  it  was  possible  to  implement 
this  module  on  the  VAX-11/780  without  modifying  the  actual 
operating  system,  this  may  not  be  possible  on  the  Nova  and 
Intel  Series  II. 

Another  man-machine  interface  consideration  was  the 
structure  of  the  network  commands.  These  commands  were 
implemented  with  position-independent  parameters.  This 
greatly  simplifies  for  the  user  the  task  of  learning  the 
network  command  structure  and  also  decreases  the  number  of 
erroneous  commands  that  will  be  entered  (Ref.  13:  11-15). 
Instead,  the  short  abbreviations,  FN  (filename),  DD 
(destination  device),  DH  (destination  host),  SD  (source 
device),  and  SH  (source  host)  are  used  to  identify  the 
parameters.  Moreover,  if  any  parameter  is  entered 
erroneously,  then  the  user  is  prompted  for  a  correct  entry 
for  that  parameter.  Missing  parameters  are  also  handled  in 
this  manner. 

The  user  has  the  option  of  entering  either  the  full 
keywords  for  the  commands  or  just  the  first  letters  of  the 
keywords.  This  keeps  a  regular  user  of  the  system  from 
being  hampered  by  long  commands  and  yet  keeps  a  novice  or 
infrequent  user  from  having  to  cope  with  cryptic  one-letter 
commands  and  parameters.  The  iist  of  keywords  in  the 
network  command  language  is  given  in  Table  10. 

The  user  "help"  protocol  was  implemented  and  can 
provide  the  user  with  all  information  required  to  use 


Table  10 


Valid  Keywords 
Network  Command  Parameter 
LOGIE 

logoiit 

TRANSFER  FILE 
HELP 


File  Transfer  Parameters 

Source  Host  (SH=) ,  Destination  Host  (DH^) 

INTEL 

NOVA 

£AX 

Source  Device  ( SD=) 

£LOPPYDISK 

HARDDISK 

TAPE 

Destination  Device  (DD=) 


CONSOLE 

£LOPPYDISK 

HARDDISK 

PRINTER 

IAPE 


Local  Host  Parameter 

Null  (Defaults  to  user  host) 

INTEL 

HOVA 

PAX 


ji 

ij 

I! 


HelB  Parameter 

£ILE  TRANSFER 
LIST  CONFIGURATION 
CESSION  COMMANDS 
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DELNET.  This  protocol  is  tiered  so  that  entry  into  to  the 
protocol  can  be  accomplished  by  simply  typing  "HELP"  and  yet 
with  the  addition  of  another  keyword  more  specific 
information  can  be  gained. 

One  factor  that  significantly  increases  the 
implementation  effort  is  the  need  for  complete  error 
detection  and  recovery.  Every  module  had  to  be  protected  to 
withstand  any  user  input  irregardless  of  its  likelihood. 
This  is  because  a  process  in  a  remote  host  aborting  due  to 
an  out-of-range  variable  or  other  invalid  input  would  never 
be  perceived  by  the  user  who  input  the  command.  Thus,  error 
recovery  would  be  almost  impossible  for  that  user. 
Therefore,  every  module  was  implemented  to  validate  the 
inputs  first  and  issue  error  messages  to  be  transmitted  back 
to  the  user  in  lieu  of  the  normal  response  if  an  invalid 
input  was  detected.  This  greatly  increased  the  size  and 
complexity  of  the  modules  and  yet  did  succeed  in  making  the 
modules  impervious  to  invalid  user  inputs. 

During  implementation,  every  attempt  was  made  to 
continue  the  practices  employed  during  the  requirements 
specification  and  design.  In  particular,  each  module  was 
implemented  such  that  it  hid  the  data  structures  and 
algorithms  employed  as  much  as  possible  from  other  modules. 
One  example  of  this  was  in  the  Transfer  File  module.  This 
module  was  passed  the  string  of  characters  that  followed  the 
transfer  file  keyword.  Thus,  the  superordinate  module  did 
not  require  any  knowledge  of  the  actual  number  of  file 
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transfer  parameters.  Data  coupling  between  modules  was  also 
an  objective  as  was  functional  cohesion  within  the  modules. 
These  objectives  were  satisfied  where  possible  in  the  design 
phase  and  yet  care  had  to  be  taken  in  the  implementation 
phase  to  insure  that  the  coupling  and  cohesion  previously 
achieved  were  not  compromised. 

Finally,  careful  consideration  was  given  to  the  data 
structures  to  be  employed.  For  example,  the  tradeoffs  of 
using  a  linked  list  versus  an  array  to  store  the  character 
string  representing  the  network  command  were  thoroughly 
studied  before  the  array  was  chosen.  The  array  offered 
faster  direct  access  to  key  positions  in  each  parameter 
field  and  was  simpler  to  implement.  On  the  other  hand,  the 
linked  list  allowed  parameter  lengths  and  command  lengths  to 
vary  more  freely  and  would  require  less  storage  space  than 
the  array.  This  would  be  especially  true  if  the  expert  mode 
was  used  most  often.  The  requirements  for  ease  cf 
maintenance  and  the  desire  to  limit  command  lengths  to  one 
packet  (128  bytes)  made  the  array  more  attractive. 

The  last  phase  of  implementation  for  each  module 
consisted  of  debugging  the  module.  Care  was  taken  to  insure 
that  changes  made  in  this  phase  did  not  destroy  the 
structure  of  the  module  originally  implemented.  The  code 
for  these  modules  is  included  in  Appendix  E.  Once  the 
modules  were  free  of  compilation  errors,  they  were  tested 
using  stubs  and  drivers  as  well  as  the  techniques  described 
in  the  following  section. 
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testing 

Because  of  the  need  for  complete  error  detection  and 
recovery,  the  testing  had  to  be  rigorous.  As  a  starting 
point,  inputs  were  chosen  to  insure  that  all  segments  of 
code  were  executed.  This  was  done  by  choosing  inputs  to 
cause  each  branch  to  be  taken.  Also,  when  a  branch  depended 
upon  a  compound  logical  expression,  inputs  were  chosen  for 
each  of  the  possible  logical  combinations. 

Equivalence  class  testing  was  also  used.  This 
procedure  entailed  breaking  the  input  into  its  components 
and  testing  combinations  of  valid  components  until  all 
equivalence  classes  of  valid  components  had  been  covered. 
Then  invalid  components  from  each  equivalence  class  were 
tested  individually.  As  an  example  of  this  method,  the 
testing  of  the  transfer  file  command  is  described.  First, 
valid  file  transfer  parameters  were  used  in  the  file 
transfer  commands  until  all  valid  keywords  had  been  included 
in  at  least  one  command.  Then,  an  invalid  file  transfer 
parameter  was  tested  with  all  other  file  transfer  parameters 
being  correct.  This  second  procedure  was  repeated  until  one 
invalid  keyword  had  been  tested  for  each  of  the  file 
transfer  parameters. 

Boundary  value  analysis  was  also  used  to  test  the 
modules.  The  values  at  the  borders  of  the  equivalence 
classes  were  tested  to  detect  "off  by  one"  errors.  This 
proved  to  be  one  of  the  most  useful  techniques.  As  an 
example  of  this  technique,  the  testing  of  the  network 
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command  parameter  is  described.  This  parameter  could  not 
exceed  twenty  characters.  To  test  the  behavior  of  the 
module  that  parsed  the  network  command,  network  command 
parameters  that  were  zero,  one,  nineteen,  twenty,  and 
twenty-one  characters  long  were  used. 

The  testing  was  done  incrementally.  As  a  module  was 
coded  and  debugged,  it  was  then  integrated  into  the  set  of 
modules  that  had  already  been  tested.  This  new  set  of 
modules  was  then  rigorously  tested  using  the  techniques 
already  mentioned.  This  procedure  was  repeated  until  the 
test  of  the  last  module  was  actually  a  test  of  the  complete 
network  command  language  interpreter.  This  method  worked 
very  well  and  allowed  interface  problems  between  modules  to 
be  isolated  quickly.  Finally,  records  were  kept  of  each  of 
these  tests  to  aid  in  maintaining  the  program.  Using  these 
documented  results,  a  modification  to  the  network  command 
language  can  be  verified  by  using  the  same  input  data  in 
addition  to  new  data  to  test  the  extensions  or  modifications 
to  the  network  command  language.  These  test  results  are 
included  as  Appendix  F. 

The  goal  of  the  testing  was  more  than  to  just  give  some 
assurance  that  the  program  executed  correctly.  It  was  also 
to  characterize  the  response  of  the  program  to  the  class  of 
possible  inputs.  While  this  is  not  an  attainable  goal,  due 
to  the  large  universe  of  inputs  that  are  possible,  it  did 
succeed  in  forcing  the  testing  effort  to  exceed  that 
required  to  convince  the  author  of  the  program  that  his 
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program  was  correct.  After  testing  was  completed,  there 
were  no  known  inputs  that  resulted  in  a  logical  error  in  the 
program. 

Summary 

The  network  command  language  interpreter  and  the  user 
help  protocol  were  both  implemented.  The  network  log  in 
procedure  was  implemented  such  that  it  was  not 
host-specific.  Also,  the  commands  were  implemented  with 
position-independent  parameters  and  made  interactive  so  that 
the  user  could  be  prompted  for  invalid  inputs.  Both  a 
novice  and  expert  mode  were  made  possible  by  the 
implementation  and  the  modules  were  implemented  to  validate 
all  inputs.  Both  information  hiding  and  a  careful  selection 
of  data  structures  were  employed  during  the  implementation. 
Finally,  the  modules  were  tested  incrementally  using  path 
analysis,  equivalence  class  testing,  and  boundary  value 
analysis . 


]  10 


YI.  .Conclusions  and  Recommendations 

From  the  outset  of  this  investigation,  the  development 
of  DELNET  was  based  upon  the  actual  requirements  of  the 
Digital  Engineering  Laboratory.  The  user  interviews  were 
employed  both  to  determine  these  requirements  and  to 
document  them.  From  these  requirements  the  functional 
requirements  of  DELNET  were  determined. 

The  functional  requirements  were  used  to  determine  the 
hardware  speci f ica ti on s  and  the  software  structured 
specification.  This  portion  of  the  investigation  was  the 
most  time-consuming.  In  determining  these  specifications, 
however,  design  decisions  had  to  be  made.  Thus,  the  process 
was  iterative. 

The  time  invested  in  the  structured  specification  did 
prove  worthwhile,  though,  when  the  design  phase  was 
started.  Because  of  the  amount  of  partitioning  that  had 
already  been  done,  the  design  proved  to  be  fairly 
straightforward.  Structured  design  techniques  were  employed 
and  then  the  software  modules  were  allocated  to  the 
processors  in  the  network. 

The  software  modules  were  also  implemented  using 
structured  techniques.  Module  coupling  and  cohesion  were 
monitored  and  structured  programming  was  employed.  The  most 
difficulty  was  encountered  in  the  interface  to  the 
VAX-11/780  operating  system  to  implement  the  "Get  User 


Command"  module  on  that  host. 


The  testing  was  conducted  thoroughly  using  branch 
analysis,  equivalence  class  testing,  and  boundary  value 
analysis.  The  implemented  modules  were  also  tested 
incrementally  which  simplified  the  overall  system  testing 
greatly. 

In  summary,  through  the  user  interviews.  Structured 
Analysis  techniques,  and  Structured  Design  techniques,  a 
top-down  design  of  DELNET  was  achieved.  All  primary 
requirements  of  the  Digital  Engineering  Laboratory  for  file 
transfer  capability  and  resource  sharing  have  been  met  in 
the  design  as  have  the  pedagogical  requirements  for 
flexibility  in  the  topology,  protocols,  and  transmission 
medium.  The  structured  approach  allowed  the  interfaces 
between  the  layers  of  protocol  to  be  clearly  defined  and 
together  the  structured  specification  and  the  module 
structure  charts  will  allow  the  implementation  of  DELNET  by 
the  follow-on  investigations. 

Reg.ominen£ati3ns 

Because  of  the  structured  approach,  it  is  possible  for 
the  implementation  to  be  accomplished  through  concurrent 
research  projects.  One  of  the  research  projects  should  be 
directed  towards  interfacing  the  host  to  the  UNID  and 
implementing  the  rest  of  the  high-level  modules.  The 
specific  tasks  involved  in  this  effort  are  listed  below: 

].  Implement  virtual  terminal  protocol  for  UNID 

2.  .  ment  file  restructuring  modules  for  each  host 
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3.  Implement  get-file,  store-file,  and  user-command 
modules  for  each  host 

4.  Implement  command  routing  table  in  each  host 

5.  Test  network  and  gather  performance  data 

6.  Update  network  users  manual 

7.  If  time  permits,  interface  Nova  to  DELNET  through  the 
Cromemco  rather  than  through  its  serial  port 

8.  If  time  permits,  add  more  hosts  to  the  network 

The  other  research  project  should  require  that  the  X.25 
modules  and  the  routing  algorithm  module  be  implemented  in 
the  UNID.  These  objectives  will  also  require  a  thorough 
understanding  of  the  UNID.  The  specific  tasks  for  this 
investigation  are  listed  below: 

1.  Implement  modules  listed  on  module  structure  charts  for 
Level  3 

a.  Suggest  using  Zilog  software  development  station  and 
PL/Z  and  then  using  code  generator  to  generate  Z-80  code  for 
the  UNID 

b.  Test  and  debug  network  protocols 

2.  Implement  modules  listed  on  module  structure  chart  for 
Level  2 

a.  Some  modules  can  be  implemented  in  PL/Z,  others  are 
performed  by  the  hardware,  others  must  be  written  in 
assembly  language 

b.  Implement  physical  links  and  test  (includes  a  fiber 
optic  link) 
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c.  Test  and  debug  link  protocols 

3.  Implement  the  routing  algorithm  module  and  its  lookup 
table  in  the  UNID. 

4.  Collect  performance  data  on  X.25  protocol  (eg., 
efficiency,  throughput,  response  times) 

With  these  two  follow-on  investigations,  DELNET  should 
have  an  initial  operational  capability.  Additional 
follow-on  efforts  to  enhance  the  network  are  also 
recommended,  however.  Because  there  was  some  interest  in  a 
distributed  database  on  DELNET,  one  should  be  implemented. 
A  design  has  been  formulated  for  this  database  in  another 
research  project  at  the  Air  Force  Institute  of  Technology 
(Ref.  17).  Also,  a  distributed  processing  layer  should  be 
developed  eventually  to  enable  the  sharing  of  software 
tools.  More  UNIDs  should  be  procured  and  more  hosts  should 
be  added  to  DELNET  to  enhance  its  usefulness  as  a  tool  for 
research  in  local  computer  networks.  Implementing  other 
protocols  on  DELNET  will  also  be  necessary  if  the  network  is 
to  be  used  for  research  in  this  area.  In  addition,  a  more 
complex  routing  algorithm  may  be  required  as  the  number  of 
nodes  increases  and  will  definitely  be  required  for  more 
complex  topologies  that  might  later  be  used.  Thus,  it  is 
recommended  the'  the  routing  algorithm  recommended  by 
Ravenscroft  also  be  implemented  (Ref.  16).  Finally,  the 
usefulness  of  the  network  will  be  enhanced  by  the  addition 
of  remote  bootstrap  capability  and  gateways  to  the  CYBER 
750,  the  ARPANET,  and  AFITNET. 
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Aeefinflia  h 

User  Interview  Results 

This  appendix  contains  a  compilation  of  the  results  of 
the  user  interviews  that  were  conducted  in  the  requirements 
analysis  phase  of  the  investigation.  These  results  provided 
the  basis  for  the  specification  of  the  DELNET  functional 
requirements  in  Chapter  II. 
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Interview  outline 


Introductory  Narrative 

I  am  in  the  preliminary  design  phase  for  the  Digital 
Engineering  Laboratory  Local  Computer  Network  (DELNET)  and 
am  attempting  to  determine  the  uses  envisioned  for  DELNET  as 
well  as  all  functional  requirements  associated  with  it.  For 
this  reason,  I  would  appreciate  any  help  that  you  can  give  me 
in  accurately  determining  these  requirements.  Hopefully,  the 
questions  that  I  have  prepared  in  the  interview  outline  will 
provide  a  framework  in  which  you  can  communicate  your  ideas 
to  me  in  this  area. 

The  interview  is  divided  into  three  sections.  The  first 
section  lists  typical  uses  of  local  computer  networks,  asks 
you  to  evaluate  the  benefits  of  having  the  capability  for  each 
use  on  DELNET,  and  then  asks  you  to  specify  which  uses  you 
would  like  to  see  implemented  first.  The  second  section  lists 
some  of  the  functional  requirements  that  must  be  determined 
and  asks  specific  questions  dealing  with  each  of  these  re¬ 
quirements.  At  the  end  of  this  section,  you  will  be  asked  to 
rate  each  of  the  functional  requirements  on  a  scale  from  not 
applicable  to  essential.  Finally,  the  third  section  requests 
that  you  express  any  ideas  that  you  have  concerning  DELNET 
that  were  not  expressed  by  your  responses  to  the  questions  in 
the  first  two  sections. 

Name  of  the  Person  Interviewed _ _ _ 

Date  of  Interview _ _ 

Courses  Taught  by  Professor _ 
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Section  I  Projected  Uses  of  DELNET 

A.  Resource  Sharing 

1.  Peripheral  Sharing — Capability  to  access  network  from 
any  terminal  and  access  any  peripheral  in  the  network  from 
any  host. 

2.  File  Access  and  Transfer — Capability  to  transfer  files 
between  the  devices  and  the  hosts  with  all  file  restructuring 
transparent  to  the  user. 

3.  Software  Tool  Sharing — Capability  to  access  programs, 
compilers,  cross-assemblers,  and  utility  routines  anywhere  in 
the  network  for  the  user's  program. 

4.  Access  to  ARPANET — Capability  to  access  ARPANET  from 
any  terminal. 

5.  Access  to  CYBER  750 — Capability  to  access  CYBER  from 
any  terminal. 

6.  Access  to  AFITNET — Capability  to  access  AFITNET  from 
any  terminal.  AFITNET  is  a  network  of  computers  that  will 
execute  much  of  the  AFIT  workload  that  is  currently  on  the 
CYBER. 

B.  Distributed  Processing — Capability  of  executing  job  pro¬ 
cesses  that  can  run  concurrently  on  different  computers. 

C.  Distributed  Databases--Capability  to  access  and  maintain 
databases  that  are  distributed  across  several  computers  in 


the  network 


D.  Fault-tolerance — Capability  to  provide  a  more  graceful 
degradation  of  user  service  when  a  network  failure  occurs. 


Projected  Use  | 

Very  lBeneficiall  Somewhat  I  Of  Little 

Beneficial!  lBeneficiall  Use 

I  Of  No 
i  Use 

1 

1 

Peripheral  I 

Sharing  I 

1 

7  1 

0 

1  1 

1  0  | 

0 

1 

1  0 

1 

1 

File  Transfers  | 

5  1 

2 

1  0  I 

0 

1  o 

1 

Software  I 

Tool  Sharing  | 

1 

2  1 

4 

1  1 

1  1  1 

0 

1 

1  o 

1 

1 

Access  to  I 

CYBER  750  ! 

1 

3  1 

3 

1  1 

1  1  1 

0 

1 

1  0 

1 

1 

Access  to  I 

AFITNET  I 

1 

3  I 

4 

!  1 

1  0  1 

0 

1 

1  o 

1 

! 

Distributed  I 

Processing  I 

1 

2  I 

1 

1  1 

1  2  1 

2 

1 

1  0 

1 

1 

Distributed  1 

Databases  1 

1 

2  1 

0 

1  1 

1  2  1 

3 

1 

1  0 

1 

1 

Fault  1 

Tolerance  1 

1 

0  I 

1 

1  1 

1  1  1 

3 

1 

1  2 

1 

1 

E.  What  group  of  things  would  you  like  to  see  implemented 
first? 

Peripheral  Sharing - 7 

File  Transfers - 6 

Software  Tool  Sharing - 1 

Access  to  CYBER  750 - 1 

Distributed  Database - 1 
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Section  II  Functional  Requirements  of  DELNET 
A.  User-oriented  Requirements 
1.  Throughput 

a.  For  the  courses  that  you  will  be  teaching  during 
the  next  four  quarters,  which  computers  do  you  expect  to  be 
utilized  by  your  students? 

b.  What  will  be  the  average  utilization? 

c.  What  will  be  the  maximum  utilization? 

Computer  Normal  Usage  Maximum  Usage 

Nova/Eclipse  8  hours/day  24  hours/day 

VAX-11/780  7  hours/day  10  hours/day 

LSI —1 1 s  10  hours/day  18  hours/day 

Intel  Series  II  2  hours/day  3  hours/day 

MIME  3  hours/day  4  hours/day 

d.  How  would  you  see  the  network  being  utilized  by 
your  students? 

File  Transfers - -3 

Peripheral  Sharing - 1 

Access  to  CYBER  750  —  1 

Simulations - 1 

Interactive  Mode - 1 

2.  Response  Time 

Do  you  forsee  any  projected  uses  of  the  network  that 
require  that  the  response  time  of  the  network  to  a  set  of 
commands  not  exceed  some  threshold? 
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No 


1 


Yes,  6  OK  file  transfers  from  CYBER  in  less  than  10  min 

Yes,  file  transfers  in  10-15  seconds 

Yes,  interactive  command  responses  in  5-7  sec 

Yes,  interactive  command  responses  in  2-3  sec 

Yes,  interactive  command  responses  in  less  than  1  sec 

Yes,  inputs  echoed  in  less  than  0.5  sec 

Yes,  general  response  time  should  be  less  than  1  min 

Yes,  standard  deviation  of  the  response  time  distri¬ 
bution  should  less  than  1/2  the  mean  response  time 

^  3.  User  Interface 

a.  Would  symbolic  device  accessing  be  desirable? 

(Making  the  actual  host  that  an  I/O  device  is  connected  to 
transparent  to  the  user) 

Yes - 7 

No - 0 

b.  Should  the  same  be  done  for  software  tools? 

Yes - 5 

No - 1 

Should  have  option - 1 

c.  What  other  features  should  the  network  present  to 


the  user? 

Overall  Transparency - 4 

Error  Recovery - 1 

User  Helps - 1 

Option  to  Waive  Transparency - 1 

System  Disk  Center - 1 

Database  Access  for  Applications  Programs - 1 
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4,  Security 

a.  Do  you  forsee  the  running  of  classified  data  or 
programs  on  the  network,  and  if  so  at  what  classification? 

Yes - 0 

No - 7 

b.  Do  you  forsee  the  need  to  protect  databases  on  the 
network  from  unauthorized  access? 

Yes - 4 

No - 2 

Maybe-1 

Access  to  the  network  needs  to  be  controlled — 1 
Varying  levels  of  access  are  needed - 1 

5.  Availability 

a.  What  is  the  minimum  percentage  of  time  that  you 
feel  that  the  network  should  be  available? 

b.  What  is  the  reason  for  giving  the  above  availabi¬ 


lity? 

99.9% - 1  (This  should  be  attainable) 

90% - 3  (Research  needs  for  digital  signal 

processing,  should  approach  availa¬ 
bility  of  machines) 

00% - 1  (Gives  some  slack) 

60% - 1  (Sufficient  to  meet  requirements  of 

digital  laboratory) 


6.  Other  User-oriented  Requirements 

Self-answering  modem  connected  to  one  node - 1 
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B.  Design-or i enled  Requirements 

These  requirements  are  not  as  user-oriented  and  you  need 
only  comment  on  those  that  you  have  interest  in. 

1.  Flexibility 

a.  What  changes  do  you  see  being  made  to  the  network 
during  the  next  few  years? 

More  hosts  and  devices  being  added  to  it - 6 

An  on-line  5  Mbit  storage  device  being  added - 1 

Being  used  more  for  non-DEL  purposes - 1 

More  networks  being  accessible  from  DELNET - 1 

Workload  changing  from  mainly  file  transfers 
to  more  interactive  command  use - 1 

More  software  development  systems  being  added - 1 

b.  How  important  do  you  feel  that  it  is  for  DELNET 
to  be  easily  reconf igurable  with  respect  to  the  following: 


Network  Subcomponents 

1  Very 

1 

| Somewhat  1  Not 

1  1 

1  Pedagogical  | 

1  Only  j 

New  Computers  and 
Devices 

1 

! 

7 

1  1 

1  0|0 

1  1 

1  0  I 

New  Topologies 

1 

0 

1  1|2 

1  4  | 

New  Protocols 

I 

1 

1  111 

1  4  I 

New  Transmission 
Medium 

1 

1 

2 

1  1 

1  111 

1  1 

1  3  1 

Important  to  be  able 

to 

va  ry 

between  serial 

and  parallel 

.  Performance  Monitoring 

What  performance  monitoring  capabilities 

Should  DELNET 

have  ? 
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Collect  accounting  data 
Collect  node  statistics 


"> 

■J 


Hardware  monitors 


Software  monitors 


As  much  as  possible 


Monitor  network  status - 1 

Detect  network  bottlenecks - 1 

Performance  monitoring  node - 1 


3.  Pedagogical 

One  of  the  purposes  of  the  network  is  to  provide  a 
learning  and  experimental  tool  for  the  students  in  such  areas 
as  digital  hardware  design,  performance  evaluation,  applica¬ 
tions  programming,  computer  networking,  and  operating  systems 
design . 

What  specific  requirements  do  you  feel  are  needed  to 
insure  that  these  goals  are  met?  (For  instance,  one  such 
suggested  requirement  is  that  DELNET  provide  the  flexibility 
for  implementation  of  different  communications  protocols, 
information  formats,  and  network  or  subnetwork  topologies) . 


Flexibility - 4 

Performance  Monitoring - 3 

Testing  a  fiber  optic  link - 1 


4.  Distributed  Processing  Language 

What  language  (s)  would  you  like  to  see  implemented 
on  all  or  most  of  the  hosts  if  a  distributed  processing 
capability  is  implemented? 
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Pascal 


7  (one  specified  UCSD  Pascal) 
6 


Ada - - 

FORTRAN 
BASIC - 1 

Ada  has  powerful  control  structures  for  distributed  processing-1 

5.  Other  design-oriented  requirements 

Are  there  any  other  design  oriented  requirements  that 
should  be  addressed? 

None - 7 

C.  Fow  would  you  rank  the  functional  requirements  for  the 
above  areas? 


Area 

1  Not 

1  Applicable 
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1 

1  Very 
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1  2 

1  0  1 
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1 
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i 

(  2 
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1  0 

1  0 
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1  1 
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Section  III  Other  Comments 

What  other  comments  or  suggestions  do  you  have  concerning 
the  projected  uses  and/or  functional  requirements  of  DELNET? 

1.  It  would  be  nice  to  have  a  general  purpose  node  for 
checking  out  student  projects  with  network  resources. 

2.  The  network  software  must  be  interrupt-driven. 

3.  It  would  be  nice  to  be  able  to  interrogate  the  net¬ 
work  to  find  a  file  that  was  sent. 

4.  The  network  should  not  be  used  for  general  software 
development. 

5.  The  requirement  to  use  all  nodes  is  probably  only 
applicable  one  percent  of  the  time. 

6.  It  should  be  easy  to  initialize  the  network  with  an 
arbitrary  subset  of  the  nodes  available  on  the  network. 

7.  The  number  of  terminals  and  their  locations  should  be 
addressed . 

8.  Top-down  decomposition  and  structured  analysis  should 
be  used  in  the  design. 
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List  of  Users  Who  Were  Interviewed 


User's  Name 
Capt  Roie  Black 

Dr.  Thomas  Hartrum 

Capt  Larry  Kizer 

Dr.  Gary  Lamont 

Capt  James  Moore 
Maj  Alan  Ross 
Maj  James  Rutledge 
Capt  Walter  Seward 

Maj  Michael  Wirth 


Position  on  Faculty 
Math  Assistant  Prof 

EE  Assistant  Prof 

EE  Instructor 

EE  Professor 

EE  Instructor 
EE  Assistant  Prof 
EE  Assistant  Prof 
EE  Assistant  Prof 

Math  Instructor 


Area  of  Interest 

Compiler  Theory, 
Numerical  Analysis 

Databases,  Performance 
Monitoring,  Operating 
Systems 

Digital  Signal 
Processing 

Computer  Engineering/ 
Computer  Science 

Computer  Networking 

Computer  Architecture 

Software  Engineering 

Computer  Architecture, 
Computer  Networking 

AFITNET  design 
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Appendix  B 

Digital  Engineering  Laboratory  Floor  Layout  Diagram 

This  appendix  contains  a  floor  layout  diagram  of  the 
Digital  Engineering  Laboratory  at  the  Air  Force  Institute  of 
Technology  School  of  Engineering.  The  locations  of  all 
computers  with  semi-permanent  locations  are  shown  as  well  as 
the  proposed  locations  of  the  Universal  Network  Interface 
Devices  (UNIDs).  Finally,  the  computer  links  that  will  be 
initially  installed  to  the  UNIDs  are  also  shown. 
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Structured  Specification 


This  appendix  contains  the  structured  specification  of 
the  software  requirements  for  DELNET.  First,  the  complete 
set  of  data  flow  diagrams  {Figures  1-32  in  the  main  body)  is 
included.  These  are  followed  by  the  data  dictionaries  for 
the  high-level  protocol,  the  host-to-host  protocol,  the 
network  protocol,  and  the  link  protocol. 


Figure  1  HD  Ccc|£nents 
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FLgjtre  2  Ccnlext  Magran 
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Figure  5  Traramt  File  (4.4)  EFT) 
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Figure  6  Control  Session  (5.0)  EFD 
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Figure  7  Help  Ifeer  (6.0)  DFD 
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Figure  9  X.25  le^l  3  Gcntext  Magran 
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141 
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Figure  II  CalHi^g  I fast  Protocol  (I)  HD 


figure  12  Bscute  Calling  tocfe  Protocol  (2)  1FD 
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Figure  13  Excite  Calling  Hoet  Ibctet  (2.1)  EFD 


144 


Figiirp  14  Eoxate  Retied  Called  Node  Ibcket  (2.3)  UD 
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Figure  16  B®cute  Called  llcfit  fticket  C4.1)  HD 


Figure  17  Bccute  Rated  Callirg  Node  Fa>'-ket  (4.3)  EFD 


figure  19.  Network  Protocol  Ccntext  ttagran 
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figure  24  Execute  Secondary  I-rmx.E  Eaclct  (1.3)  UT) 
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Figure  25  Execute  S-Frore  Fespcnse  (1 .4)  1I-D 
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WJtespcnsR 


Figure  26  Execute  IHfere  Rerpcnse  (1.5)  UD 
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Figure  28.  Bcecute  H3D  ftotxjcol  it  Secondary  Node  0) 


Figure  29.  Bcecute  Priimry  I-Fnme  Racket  (3.3)  EFD 
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FigJre  30.  Execute  S-Fnrv?  Contturri  (3.4)  EFT) 
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Figjrelt.  V.  nrnv  Scmiiry  InfcrmUcri  Blrcks  (2.6)  IFD 
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DATA  DICTIONARY 
FOR  HIGH-LEVEL  PROTOCOLS 


DATA  ELEMENT  NAME: 
ALIASES: 

VALUES  AND  MEANINGS: 


NOTES : 


DATA  ELEMENT  NAME: 
ALIASES: 

VALUES  AND  MEANINGS: 


NOTES: 


DATA  ELEMENT  NAME: 
ALIASES: 

VALUES  AND  MEANINGS: 


NOTES: 


DATAFLOW  NAME: 

ALIASES: 

COMPOSITION: 


NOTES: 


DATAFLOW  NAME: 

ALIASES: 

COMPOSITION: 

NOTES: 


ACTIVE-DEVICE-NAME 

NONE 

NAME  OF  A  DEVICE  THAT  IS  ATTACHED  TO  AN 
ACTIVE  HOST  ON  THE  NETWORK . 

NOS  LAYER 


ACTIVE-HOST-NAME 

NONE 

NAME  OF  A  HOST  THAT  IS  ACTIVE  ON  THE 
NETWORK. 

NOS  LAYER 


ERROR-MESSAGF-FT 

NONE 

ERROR  MESSAGE  STATING  WHY  THE  FILE  CANNOT 
BE  PROPERLY  TRANSFERRED 
NOS  LAYER 


FILE 

NONE 


FILE  =  FILE-NAME 

+  FILE-TYPE 
+  FILE-LENGTH 
+  {FILE-CHARACTER} 
APPLICATIONS  I, AYER 


FILE-BLOCK 

NOME 

FILE-BLOCK  =  1 { FILE-CHARACTER } 1 0 ? 4 
APPLICATIONS  LAYER 


164 


DATA  ELEMENT  NAME: 

AL I  AS  ES  : 

VALUES  AND  MEANINGS: 


NOTES : 


DATA  ELEMENT  NAME: 
ALIASES: 

VALUES  AMD  MEANINGS: 


NOTES: 


DATA  ELEMENT  NAME: 
ALIASES: 

VALUES  AND  MEANINGS: 


NOTES : 


DATA  ELEMENT  NAME: 
ALIASES: 

VALUES  AND  MEANINGS: 


NOTES: 


DATA  ELEMENT  NAME: 
ALIASES: 

VALUES  AND  MEANINGS: 


NOTES: 


FILE-CHARACTER 

NONE 

ANY  ASCII  OR  ERCDIC  CHARACTER  OR  8  BINARY 
DIGITS 

APPLICATIONS  LAYER 


FILE-DEST-DEVICE-NAME 

NONE 

NAME  OP  THE  DEVICE  TO  WHICH  THE  FILE  IS  TO 
BE  TRANSFERRED.  NAME  MUST  CORRESPOND  TO 
ONE  OF  THOSE  IN  THE  LIST-OF-ACTIVE-HOSTS . 
NOS  LAYER 


FILE-DEST-HGST-NAME 

NONE 

NAME  OP  THE  HOST  TO  WHICH  THE  FILE  IS  TO 
BE  TRANSFERRED.  NAME  MUST  CORRESPOND  TO 
ONE  OP  THOSE  IN  THE  LI ST-OF -ACTIVE-HOSTS . 
NOS  LAYER 


FILE-LENGTH 

NONE 

A  10-BIT  FIELD  THAT  SPECIFIES  THE  FILE 
LENGTH  IN  FILE-BLOCKS  AND  THUS  ALLOWS 
FILE-LENGTHS  UP  TO  IK  BLOCKS  OR  1  KBY^E 
APPLICATIONS  LAYER 


F I L F -NAME 
NONE 


ANY  CHARACTER  STRING  CHOSEN  BY  THE  USER  TO 
IDENTIFY  THE  FILE 
NOS  LAYFR 


16  S 


DATA  ELEMENT  NAME: 
ALIASES: 

VALUES  AND  MEANINGS: 


NOTES : 


DATA  ELEMENT  NAME: 
ALIASES: 

VALUES  AMD  MEANINGS: 


NOTES : 


DATA  ELEMENT  NAME: 
ALIASES: 

VALUES  AMD  MEANINGS: 


NOTES: 


DATAFLOW  NAME: 
ALIASES: 
COMPOSITION : 


NOTES: 


DATAFLOW  NAME: 

ALIASES: 

COMPOSITION: 


NOTES: 


FILE-SOURCE-DEVICE-NAME 

NONE 

NAME  OF  DEVICE  THAT  CONTAINS  THE  FILE  TO 
PE  TRANSFERRED.  NAME  MUST  CORRESPOND  TO 
ONE  IN  THE  LIST-OF-ACTIVE-DEVICE-NAMES . 

NOS  LAYER 


FI  I,E- SOURCE; -IIOST-NAME 
NONE 

NAME  OF  HOST  THAT  CONTAINS  THE  FILE  TO  BE 
TRANSFERRED.  NAME  MUST  CORRESPOND  TO  ONE 
IN  THE  LIST-OF -ACTIVE-HOSTS. 

NOS  LAYER 


FILE-TRANSFER-PROCEDURE 

NONE 

A  SHORT  EXPLANATION  OF  HOW  TO  USE  THE 
NETWORK  PILE  TRANSFER  COMMAND 
NOS  LAYER 


F ILF -TRAN  SFER-PR OCEDURE-REO 
NONE 

FI LP-TRAN SFER-PR OCEDURE-REQ  = 

GENERAL- IN EO-PEO 
+  " ,  FILE  TRANSFER" 
NOS  LAYER,  APPLICATIONS  LAYER 


FII. E-TRAN  SFER-MESSACE 
NONE 

F  T  LE--TRAN  SFER-MESSACE  =  USER-ID  + 

[  FILE -TRAN  SFERRFD-M F,  S SAC E 
I  ERROR-MESSAGE -FT  1 
EILF-TRAN SFERRED-ME SSACE  = 

[  MODI  FI  ED-n  LF-NAME. 

+  E I  I.F-DF.  ST- HOST-NAME 
+  FILE-DEST-DEVICE-NANF  ] 

NOS  LAYER 
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DATA  EI.FMENT  NAME:  FILE-TYPE 

ALIASES:  NONE 

VALUES  AMD  MEANINGS: 

A  3-BIT  FIELD  SHOWING  WHETHER  ARC 
EBCDIC,  BINARY,  FTC 

NOTES:  APPLICATIONS  LAYER 


DATAFLOW  NAME:  GENERAL- IN FO-REO 

ALIASES:  NONE 

COM POSITION: 

GENERAL- IN FO-REO  =  NETWORK-ID  +  "HELP" 
NOTES:  NOS  LAYER,  APPLICATIONS  LAYER 


DATA.  ELEMENT  NAME:  GET- COMMAND 

ALIASES:  NOME 

VALUES  AND  MEANINGS: 

THE  CHARACTER  STRING,  "NOS, GET  FILE 
MOTES:  APPLICATIONS  LAYER 


DATAFLOW  NAME:  GET-FILE-COMMAND 

ALIASES:  NOME 

COMPOSITION: 

GET-  F I  I,F  -  COM  MAN  0  =  USER-ID 
+  GET-COMMAND 
+  FILE-NAME 

+  FILE -SOURCE -HOST-NAME 
+  F I LE-SOURCE -DEVICE -NAME 
+  FILF-DEST-HOST-NANE 
+  FILF-DEST-DEVICE-NAMF 
NOTES:  APPLICATIONS  LAYER 


DATA  ELEMENT  NAME:  GOODBYE 

ALIASES:  NONE 

VALUES  AND  MEANINGS:  "USER  LOGGED  OUT  OF  NETWORK" 
NOTES:  NOS  LAYER 


DATAFLOW  NAME: 
ALIASES: 
COMPOSITION : 


NOTES: 


DATAFLOW  NAME: 

ALIASES: 

COMPOSITION: 


NOTES: 


DATAFLOW  NAME: 

ALIASES: 

COMPOSITION: 


NOTES: 


DATAFLOW  NAME: 
ALIASES: 

COM POSITION: 


MOTES: 


DATAFLOW  NAME: 
ALIASES: 
COMPOSITION : 

NOTES: 


HELP- INFORMATION 
NONE 

HELP-INFORMATION  = 

[MENU-SELECTION 
I  FILE-TRANSFER-PROCEDURE 
1 L I ST-OF -ACTIVE -DEVI CE -NAMES 
| LOGOUT- INFO] 

NOS  LAYF R 


HOST-STRUCTURED-FILF 

NONE 

HOST-STRUCTURED-FILE  =  MODI  FI ED-FILE-NAME 

+  FILE-TYPE 
+  FILE-LENGTH 
+  {FILE-CHARACTER} 

APPLICATIONS  LAYER 


LIST-OF-ACTIVE-DEVICE-NAMES 

NONE 

LIST-OF-ACTIVE-DEVICE-NAMES  = 

{ACTIVE -DEVICE -NAME} 

NOS  LAYER 


LIST-OF-ACTIVE-DEV ICE -NAME S-REQ 
NONE 


LIST-OF-ACTIVE-DEVICE-NAMES-REO  = 
GENERAL- IN FO-REO 
+  " f LIST  ACTIVE  DFVICES" 
NOS  LAYER,  APPLICATIONS  LAYER 


LI ST-OF -ACTIVE-HOSTS 
NONE 


LIST-OF -ACTIVE-HOSTS  =  {ACTIVE-HOST-NAME] 
NOS  LAYER 
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DATAFLOW  NAME: 

ALIASES: 

COMPOSITION: 


NOTES: 


DATA  ELEMENT  NAME: 
ALIASES: 

VALUES  AND  MEANINGS: 


NOTES: 


DATA  ELEMENT  NAME: 
ALIASES: 

VALUES  AND  MEANINGS: 


NOTES: 


DATAFLOW  NAME: 
ALIASES: 
COMPOSITION : 


NOTES: 


DATAFLOW  NAME: 
ALIASES: 
COMPOSITION : 


1 


LOCAL-COMMAND 

NONE 

LOCAL-COMMAND  =  [ VALID-LOCAL-OS- INPUT 

| INVALID-INPUT] 

NOS  LAYER 

THE  USER  IS  "LOCAL"  TO  THE  HOST  THAT  HE 
DESIGNATES  WHEN  HE  SIGNS  ONTO  THE  NETWORK, 
NOT  NECESSARILY  THE  ONE  TO  WHICH  THE 
TERMINAL  IS  CONNECTED. 


LOCAL-HOST-NAME 

NONE 

THE  NAME  OF  THE  HOST  MACHINE  TO  WHICH  THE 
USER  WISHES  TO  BE  "LOCAL" 

NOS-LAYER 


LOCAL-RESPONSE 

NONE 

LOCAL  OPERATING  SYSTEM'S  RESPONSE  TO  A 
LOCAL  INPUT 
NOS  LAYER 


LOGON-COMMAND 

NONE 


LOGON-COMMAND  =  NETWORK -ID 
+  "LOGON" 

+  (LOCAL-IIOST-NAME) 

NOS  LAYER 


LOGON-MESSAGE 

NONE 

LOGON-MESSAGE  =  NETWORK-INTRODUCTION 

+  LIST-OF-ACTIVE-HOSTS 
+  (LOCAL-HOST-NAME) 


NOTES: 


NOS  LAYER 


DATAFLOW  NAME: 
ALIASES: 
COMPOSITION : 

NOTES: 


DATAFLOW  NAME: 

ALIASES: 

COMPOSITION: 


NOTES: 


DATAFLOW  NAME: 

ALIASES: 

COMPOSITION: 


NOTES: 


DATAFLOW  NAME: 

ALIASES: 

COMPOSITION: 


NOTES: 


DATA  ELEMENT  NAME: 
ALIASES: 

VALUES  AMD  MEANINGS: 


NOTES: 


LOGOUT-COMMAND 

NONE 

LOGOUT-COMMAND  =  NETWORK-ID  +  "LOGOUT" 
NOS  LAYER 


LOGOUT- IN FO-REQ 
NONE 


LOGOUT- IN FO-REQ  =  GENERAL- IN FO-REQ 

+  ", LOGOUT  PROCEDURE" 
NOS  LAYER,  APPLICATIONS  LAYER 


LOGOUT-MESSAGE 

NONE 

LOGOUT-MESSAGE  =  GOODBYE 

+  LIST-OF -FILE-TRANSFERS 
LIST-OF -FILE-TRANSFERS  = 

{FILE-TRANSFERRED-MESSAGE} 

NOS  LAYER 


MENU-SELECTION 

NONE 

MENU-SELECTION  =  USER-ID 

+  NETWORK-COMMAND-SYNTAX 
+  {ACTIVE-HOST-NAME 
+  {ACTIVE-DEVICE-NAME}} 

NOS  LAYER 


MODI FI  ED -FILE -NAME 
NONE 

NAME  GIVEN  TO  THE  TRANSFERRED  FILE.  IT 
WILL  CORRESPOND  TO  FILE-NAME  UNLESS 
FILE-NAME  IS  TOO  LONG  OR  CONTAINS  ILLEGAL 
CHARACTERS  FOR  THE  HOST  OPERATING  SYSTEM 
TO  WHICH  THE  FILE  WAS  TRANSFERRED. 

NOS  LAYER,  APPLICATIONS  LAYER 
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DATAFLOW  NAME: 

ALIASES: 

COMPOSITION: 

NOTES: 


DATA  ELEMENT  NAME: 
ALIASES: 

VALUES  AND  MEANINGS: 


NOTES: 


DATA  ELEMENT  NAME: 
ALIASES: 

VALUES  AND  MEANINGS: 
NOTES : 


DATA  ELEMENT  NAME: 
ALIASES: 

VALUES  AND  MEANINGS: 


NOTES : 


DATAFLOW  NAME: 

ALIASES: 

COMPOSITION: 


NOTES: 


NETWORK-COMMAND 

NONE 

NETWORK-COMMAND  =  NETWORK-ID 

+  CHARACTER-STRING 

NOS  LAYER 


NETWORK-COMMAND-SYNTAX 

NONE 

SUMMARY  OF  THE  NETWORK  COMMANDS  AVAILABLE 
AND  THEIR  SYNTAXES 
NOS  LAYER 


NETWORK-ID 

NONE 

NETWORK-ID  =  "NETWORK," 
NOS  LAYER 


NETWORK -INTRODUCTION 
NONE 

A  SHORT  PARAGRAPH  WELCOMING  THE  USER  TO 
THE  NETWORK  AND  STATING  HOW  TO  GET  FURTHER 
INFORMATION  THROUGH  THE  GENERAL-INFO-REQ . 
NOS  LAYER 


NETWORK-RESPONSE 

NONE 

NETWORK-RESPONSE  =  USER-ID 

+  [TRANSMITTED-FILE-TRANSFER-MESSAGE 
ITRANSMITTED-LOGON-MESSAGE 
[ TRAM  SMITTED-LOGOUT-MESSAGE 
I  TRAN SMITTED-HELP- INFORMATION] 

NOS  LAYER 
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DATAFLOW  NAME 

ALIASES'. 

COMPOSITION: 


NETWORK-STRUCTURED-FILE 

NONE 


NOTES: 


NETWORK-STRUCTURED-FILE 


APPLICATIONS  LAYER 


FILE-NAME 
+  FILE-TYPE 
+  FILE-LENGTH 
+  {FILE-BLOCK} 


DATA  ELEMENT  NAME:  PORT-NUMBER 

ALIASES:  NONE 

VALUES  AND  MEANINGS: 

IF  THE  HOST  HAS  MULTIPLE  INPUT  PORTS,  THEN 
THIS  CORRESPONDS  TO  THE  NUMBER  OF  THE  PORT 
THROUGH  WHICH  THE  USER  IS  MAKING  HIS 
INPUTS  TO  THE  HOST.  IF  THE  HOST  HAS  ONLY 
ONE  INPUT  PORT,  THEN  PORT-NUMBER  IS 
ASSIGNED  THE  VALUE  "1". 

NOTES:  NOS  LAYER,  APPLICATIONS  LAYER 


DATAFLOW  NAME: 

ALIASES: 

COMPOSITION: 


NOTES: 


ROUTED-LOCAL-COMMAND 

NONE 


ROU  TED- LOCAL- COM  MAN  D 
NOS  LAYER 


LOCAL-COMMAND 
+  USER-ID 


DATAFLOW  NAME: 

ALIASES: 

COMPOSITION: 


NOTES: 


ROUTED-LOCAL-RESPONSE 

NONE 


ROUTED-LOCAL-RESPONSE 
NOS  LAYER 


LOCAL-RESPONSE 
+  USER-ID 


DATA  ELEMENT  NAME:  STORE-COMMAND 

ALIASES:  NONE 

VALUES  AND  MEANINGS: 

THE  CHARACTER  STRING,  "NOS, STORE  FILE" 
NOTES:  APPLICATIONS  LAYER 
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DATAFLOW  NAME 

ALIASES: 

COMPOSITION: 


STORE-FILE-COMMAND 

NONE 


NOTES: 


DATA  ELEMENT  NAME: 
ALIASES: 

VALUFS  AND  MEANINGS: 
NOTES: 


DATAFLOW  NAME: 

ALIASES: 

COMPOSITION: 


NOTES: 


DATAFLOW  NAME: 

ALIASES: 

COMPOSITION: 


NOTES: 


STORE-FILE-COMMAND  =  USER-ID 

+  STORE-COMMAND 
+  FILE-DEST-DEVICE-NAME 
APPLICATIONS  LAYER 


TRANSFER-COMMAND 

NONE 

THE  CHARACTER  STRING,  ", TRANSFER  FILE" 
NOS  LAYER,  APPLICATIONS  LAYER 


TRAN  SMITTED-FILE-TRAN  SFER-COMMAND 
NONE 

TRAN SMITTED-FILE-TRAN SFER-COMMAND  = 

TRAN  SFER-COMMAND 
+  FILE-TRANSFER-FIELDS 
FILE-TRANSFER-FIELDS  = 

FILE-NAME 

+  FILE-SOURCE-HOST-NAME 
+  FILE-SOURCE-DEVICE-NAME 
+  FILE-DEST-HOST-NAME 
+  FILE-DEST-DEVICE-NAME 
NOS  LAYER,  APPLICATIONS  LAYER 


TRANSMITTED-HELP-REQUEST 

NONE 

TRANSMITTED-HELP-REQUEST  =  USER-ID 

+  [ GENERAL- INFO-REQ 
I SPECIFIC-INFO-REQ] 

SPECIFIC-INFO-REQ  = 

[FILE-TRANSFER- INFO-REQ 
I  LOGOUT- INFO-REQ] 
FILE-TRANSFER-INFO-REQ  = 

[FILE-TRANSFER-PROCEDURE-REQ 
I LIST-OF-ACTIVE-DEVICE-NAMES-REQ] 
NOS  LAYER,  APPLICATIONS  LAYER 
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DATAFLOW  NAME: 

ALIASES: 

COMPOSITION: 


NOTES: 


DATAFLOW  NAME: 

ALIASES: 

COMPOSITION: 


NOTES: 


DATAFLOW  NAME: 

ALIASES: 

COMPOSITION: 


MOTES: 


DATAFLOW  NAME: 

ALIASES: 

COMPOSITION: 

NOTES: 


DATA  ELEMENT  NAME: 
ALIASES: 

VALUES  AND  MEANINGS: 


NOTES: 


TRANSMITTED -NETWORK -COMMAND 
NONE 

TRANSMITTED-NETWORK-COMMAND  =  USER- ID 
+  [TRANSMITTED-FILE-TRANSFER-COMMAND 
I  TRAN  SMITTED-SESSION-CONTROL-COMMAND 
( TRANSMITTED-HELP-REQUEST] 

NOS  LAYER 


TRAN  SM I TTED -NETWORK -STRUCTU RED-FILE 
NONE 

TRANSMITTED-NETWORK-STRUCTURED-FILE  = 
USER-ID 

+  FILE-DEST-HOST-NAME 
+  FILE-DEST-DEVICE-NAME 
+  NETWORK-STRUCTURED-FILE 
APPLICATIONS  LAYER 


TRAN  SM  I TTED-SE  SSI  ON -CONTROL -COM  MAI-1  D 
NONE 

TRAN SMI TTED- SESSION- CONTROL -COMMAND  = 

USER-ID 

+  [LOGON-COMMAND 
[LOGOUT-COMMAND] 
NOS  LAYER,  APPLICATIONS  LAYER 


USER-COMMAND 

NONE 

USER-COMMAND  =  [ LOCAL-COMMAND 

[NETWORK -COMMAND] 

NOS  LAYER 


USER-HOST-NAME 

NOME 

NAME  OF  THE  HOST  THROUGH  WHICH  THE  USER  IS 
MAKING  HIS  INPUTS  TO  THE  NETWORK.  NAME 
MUST  CORRESPOND  TO  ONE  ON  THE 
LIST-OF -ACTIVE-HOSTS. 

NOS  LAYER,  APPLICATIONS  LAYER 
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DATAFLOW  NAME: 

ALIASES: 

COMPOSITION: 

NOTES: 


DATAFLOW  NAME: 

ALIASES: 

COMPOSITION: 


NOTES: 


DATA  ELEMENT  NAME: 
ALIASES: 

VALUES  AND  MEANINGS: 


NOTES: 


USER-ID 

NONE 

USER- ID  =  USER-HOST-NAME  +■  PORT-NUMBER 
NOS  LAYER 


USER-RESPONSE 

NONE 

USER-RESPONSE  =■  [NETWORK-RESPONSE 
[LOCAL-RESPONSE] 

NOS  LAYER 


VALID-LOCAL-OS-INPUT 

NONE 

ANY  VALID  INPUT  FOR  THE  OPERATING  SYSTEM 
OF  THE  HOST  THAT  THE  USER  IS  SIGNED  ONTO 
ON  THE  NETWORK. 

NOS  LAYER 
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FILE  DEFINITIONS 


FILE  OR  DATABASE  NAME: 
ALIASES: 

COMPOSITION: 


ORGANIZATION: 

NOTES: 


COMMAND -ROUTING -TABLE 
NONE 

COMMAND-ROUTING-TABLE  = 

{USER-ID 

+  LOCAL-HOST-NAME} 
SEQUENTIAL  BY  USER- ID 
NOS  LAYFR 


FILE  OR  DATABASE  NAME: 
ALIASES: 

COMPOSITION: 


ORGANIZATION: 

NOTES: 


FILE-TRANSFER-LOG 

NONE 

FILE-TRANSFER-LOG  = 

{USER  ID 

+  FILE-TRANSFER-FIELDS} 

PILE 

NOS  LAYER 


FILE  OR  DATABASE  NAME: 
ALIASES: 

COMPOSITION: 


ORGANIZATION: 


NOTES: 


NETWORK -CONFIGURATION 
NONE 

NETWORK-CONFIGURATION  = 

{ACTIVE-HOST-NAME 
+  {ACTIVE-DEVICE-NAME}} 

ALPHABETICALLY  KEYED  FIRST  ON 

ACTIVE-HOST-NAME  THEN  ON 

ACT  IVE-DEVI CE-NAMF. 

NOS  LAYER 
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PROCESS  SPECIFICATIONS 


PROCESS  NAME:  DETERMINE  COMMAND  TYPE 

PROCESS  NUMBER:  1.0 

PROCESS  DESCRIPTION: 

If  USER-COMMAND  contains  NETWORK-ID 
then  USER-COMMAND  =  NETWORK -COMMAND 
otherwise  USER-COMAND  =  LOCAL-COMMAND 


PROCESS  NAME:  SEND  COMMAND  TO  HOST  WITH  NOS 

PROCESS  NUMBER:  2.0 

PROCESS  DESCRIPTION: 

Send  NETWORK -COMMAND  to  NOS-HOST  using  FOST-TO-HOST-PROTOCOI, 
Set  SOURCE-FIELD  to  USER-HOST-NAME 
Set  DEST-FI ELD  to  NOS-HOST-NAME 
Set  INFO-FIELD  to  NETWORK -COMMAND 


PROCESS  NAME:  DETERMINE  NETWORK  COMMAND  TYPE 

PROCESS  NUMBER:  3.0 

PROCESS  DESCRIPTION: 

If  TRANSMITTED-NETWORK-COMMAND  has  the  following 
COMMAND-FIELD, 

Case  1  TRANSFER-COMMAND: 

then  TRANSMITTED-NETWORK-COMMAND  = 

TRAN  SMITTED-FILE-TRAN  SFER- COMMAND 
Case  2  LOGON-COMMAND  or  LOGOUT-COMMAND: 
then  TRANSMITTED-NETWORK-COMMAND  = 

TRAN  SM I TTED- SESSION -CONTROL -COMM AND 
Case  3  GENERAL-INFO-REQ : 

then  TRANSMITTED-NETWORK-COMMAND  = 
TRANSMITTED-IIELP-REQUEST 
Otherwise  reject  TRANSMITTED-NETWORK-COMMAND 


PROCESS  NAME:  SEND  GET-FILE-COMMAND  TO  FILE-SOURCE-HOST 

PROCESS  NUMBER:  4.1 

PROCESS  DESCRIPTION: 

Send  GET-FII.E-COMMAND  to  FILE-SOURCE-HOST  using 
HOST— TO— HOST- PROTOCOL 

Set  SOURCE-FIELD  to  NOS-HOST 

Set  DEST-FI ELD  to  FILE-SOURCE-HOST 

Set.  INFO-FTELD  to  GET-FII.E-COMMAND 
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PROCESS  NAME:  GET  FILE  FROM  SOURCE-DEVICE 

PROCESS  NUMBER:  4.2 

PROCESS  DESCRIPTION: 

Call  FILE-FETCH-ROUTINE  in  the  SOURCF.-HOST-OS 
Use  FILE-NAME  and  FILE-SOURCE-DEVICE-NAME 
from  GET- FILE -COMMAND 


PROCESS  NAME:  RESTRUCTURE  FILE  FOR  NETWORK 

PROCESS  NUMBER:  4.3 

PROCESS  DESCRIPTION: 

Copy  FILE-TYPE  into  FILE-TYPE-FIELD 

Convert  FILE-LENGTH  to  FILE-LENGTH-IN-BYTES  and  copy  into 
FILE-LENGTH -FI  ELD 

Divide  FILE  into  FILE-BLOCKS  and  fill  PARTI AL-LAST-FI LF- 
BLOCK  with  NULLS 


PROCESS  NAME:  TRANSMIT  FILE  TO  DEST  HOST 

PROCESS  NUMBER:  A. 4 

PROCESS  DESCRIPTION: 

Send  NETWORK-STRUCTURED-FILE  to  FILE-DEST-HOST  using 
HOST-TO-HOST-PROTOCOL 

While  there  are  FILE-BLOCKS  remaining  do 
Set  SOURCE-FIELD  to  FILE-SOURCE-HOST-NAME 
Set  DEST-FI ELD  to  FILE-DEST-HOST-NAME 
Set  INFO-FIELD  to  FILE-BLOCK 


PROCESS  NAME:  RESTRUCTURE  FILE  FOR  DEST  HOST 

PROCESS  NUMBF'R :  d  .  5 

PROCESS  DESCRIPTION: 

Set  FILE-TYPE  to  FILE-TYPE-FIELD 

Set  FILE-LENGTH-IN-BYTES  to  F ILL-LENGTH -IN-BYTES-FI ELD 
Convert  FILE-LENGTH -IN -BYTES  to  FILE-LENGTH 
Merge  FILE-BLOCKS  into  HOST-STRUCTURED-FILE 


PROCESS  NAME:  STORE  FILE  ON  DEST  DEVICE 

PROCESS  NUMBER:  4.6 

PROCESS  DESCRIPTION: 

Cal]  F  T  I,  E-STORE- POUT  IN  F  j  r.  the  PEST-HOST-OS 

Use  FILE-NAME  and  F I LF-DEST-DEVICF-NAME  from  STORE-COMMAND 
and  store  HOST-STRUCTURED-F I  LI 
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PROCESS  NAME:  DETERMINE  SESSION  COMMAND  TYPE 

PROCESS  NUMBER:  5.1 

PROCESS  DESCRIPTION: 

If  TRAN SM I TTED-SESSI ON -CONTROL -COMMAND  contains  "LOGON" 

then  TRAN  SMI TTED-SESSI ON -CONTROL-COMMAND  is  a  LOGCN -COMMAND 
otherwise  TRAN SMI TTED-SESSI ON-CONTROL -COMMAND  is  a 
LOGOUT-COMMAND 


PROCESS  NAME:  LOG  USER  ON  NETWORK 

PROCESS  NUMBER:  5.2 

PROCESS  DESCRIPTION: 

If  LOCAL-HOST-NAME  is  included  in  the  LOGON-COMMAND 

then  enter  LOCAL-HOST-NAME  into  the  COMMAND-ROUTING-TABLE 
using  the  USER-ID  in  the  LOGON-COMMAND 
otherwise  access  NETWORK-CONFIGURATION-TABLE  using 
USER-ID  and  set  COMMAND-ROUTING-TABLE  to  USER-HOST-NAME 
Access  NETWORK-CONFIGURATION-TABLE  and  get  LIST-OF-ACTIVE- 
HOSTS 

Output  LOGON-MESSAGE 


PROCESS  NAME:  LOG  USER  OFF  NETWORK 

PROCESS  NUMBER:  5.3 

PROCESS  DESCRIPTION: 

Reset  LOCAL-HOST-NAME  in  COMMAND-ROUTING-TABLE  to  USER- HOST-NAME 
Get  LIST-OF-FILE-TRAN SFER- MESSAGES  from  FILE-TRANSFER-LOG 
Output  LOGOUT-MESSAGF 


PROCESS  NAME:  DETERMINE  HELP- INFORMATION  REQUESTED 

PROCESS  NUMBER:  5.1 

PROCESS  DESCRIPTION: 

If  TRANSMITTED-HELP-REQUEST  contains  the  HELP-FIELD 
Case  1  "FILE  TRANSFER": 

Then  TRAN  SM  I TTFD- HELP- REQUEST  is  a  FILE'-TRAN  SFER- 
PROCEDURE-REQ 

Case  2  "LIST  ACTIVE  DEVICES": 

Then  TPANSMITTED-UELP-REOUEST  is  a  LIST-ACTIVE- 
DEVICE  -NAMES  -REQ 
Case  3  "LOGOUT  PROCEDURE": 

Then  TRANSMITTED-HELP-REQUEST  is  a  LOGOUT- INFO- REQ 
Otherwise,  TRANSMITTED-HELP-REQUEST  is  a  GENFRAL- 
INFO-REQ 
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PROCESS  NAME:  PROVIDE  GENERAL  HE WORK  INTRODUCTION 

PROCESS  NUMBER:  6.2 

PROCESS  DESCRIPTION: 

Output  MENU-SELECTION  and  USER-ID 


PROCESS  NAME:  PROVIDE  PROCEDURE  FOR  TRANSFERRING  FILES 

PROCESS  NUMBER:  6.3 

PROCESS  DESCRIPTION: 

Output  FILE-TRANSFER-PROCEDURE  and  USER-ID 


PROCESS  NAME:  PROVIDE  LIST-OF -ACTIVE-DEVICE-NAMES 

PROCESS  NUMBER:  6.4 

PROCESS  DESCRIPTION: 

Access  NE WORK -CONFIGURATION-TABLE 

Output  LIST-OF-ACTIVE-DEVICE-NAMES  and  USER- ID 


PROCESS  NAME:  PROVIDE  PROCEDURE  FOR  LOGGING  OFF  NETWORK 

PROCESS  NUMBER:  6.5 

PROCESS  DESCRIPTION: 

Output  LOGOUT- INFO  and  USER-ID 


PROCESS  NAME:  SEND  MESSAGF  TO  USER-HOST 

PROCESS  NUMBER:  7.0 

PROCESS  DESCRIPTION: 

Send  NETWORK-RESPONSE  to  USER-HOST  usir.q  HOST— TO-HCST- 
PROTOCOL 

Set  SOURCE-FIELD  to  FILR-DEST-HOST 
Set  DEST-FI ELD  to  USER-HOST-NAME 
Set  INFO-FIELD  to  NETWORK-RESPONSE 


PROCESS  NAME:  ROUTE  LOCAL  COMMAND 

PROCESS  NUMBER:  8.0 

PROCESS  DESCRIPTION: 

Find  LOCAL-HOST-NAME  for  USER  fron  COMMAND-ROUTING-TABLE 
Use  HOST-TO- HO ST- PROTOCOL  to  send  LOCAL-COMMAND  to 
LOCAL-HOST 

Set  SOURCE-FIELD  to  USER-HOST-NAME 
Set  DEST-FTELD  to  LOCAL -HOST-NAME 
Set  INFO-ri ELD  to  I OCAL-COMMAND 


I  R0 


EXECUTE  ROUTED -LOCAL -COMMAND 
9.0 


r 


PROCESS  NAME: 

PROCESS  NUMBER: 

PROCESS  DESCRIPTION: 

Use  I.OCAL-OPERATING-SYSTEM  to  execute  ROUTED-LOCAL-COMMAND 


PROCESS  NAME:  POUTE  LOCAL  RESPONSE 

PROCESS  NUMBER:  10.0 

PROCESS  DESCRIPTION: 

Send  LOCAL-RESPONSE  to  USER-HOST  using  HOST-TO-HCST- 
PROTOCOL 

Set  SOURCE-FIELD  to  LOCAL-HOST-NAME 
Set  DEST-FI ELD  to  USER-HOST-NAME 
Set  INFO-FIELD  to  LOCAL-RESPONSE 


AD-A100  022  AIR  FORCE  INST  OF  TECH  WRIGHT-PATTERSON  AFB  OH  SCHOO— ETC  F/6  9/2 

DESIGN  OF  A  LOCAL  COMPUTER  NETWORK  FOR  THE  AIR  FORCE  INSTITUTE  — ETCIUI 
MAR  B1  VC  HOBART 

UNCLASSIFIED  AFIT/GE/EE/01M-3  NL 


DATA  DICTIONARY 


FOR 


DATA  ELEMENT  NAME: 
ALIASES: 

VALUES  AND  MEANINGS: 
NOTES : 


DATAFLOW  NAME: 

ALIASES: 

COMPOSITION: 


NOTES: 


DATA  ELEMENT  NAME: 
ALIASES: 

VALUES  AND  MEANINGS: 
NOTES : 


DATAFLOW  NAME: 
ALIASES: 
COMPOSITION: 
NOTES: 


DATAFLOW  NAME: 

ALIASES: 

COMPOSITION: 

NOTES: 


DATAFLOW  NAME: 

ALIASES: 

COMPOSITION: 


NOTES: 


X . 2  5  LEVEL  3  PROTOCOL 


CALL-CONNECTED-PACKET 

NONE 

OCTET  3  =  (00001111) 

CALLING  NODE  AND  HOST  PROTOCOL  LAYERS 


CALL-CONNECTION-PACKET 

NONE 

CALL-CONNECTION-PACKET  = 
[CALL-CONNECTED-PACKET  |  CALLING- 
NODE  -CLEAR-INDI  CATION-  PACKET] 
CALLING  NODE  PROTOCOL  LAYER 


CALLED-HOST- INTERRUPT-CONFIRMATION- 
PACKET 
NONE 

OCTET  3=(00100111) 

CALLED  HOST  AND  NODE  PROTOCOL  LAYER 


CALLED-HOST-LEVEL-3 -PACKET 
CALLED-HOST-TO-CALLED-NODE-LEVEL-3 -PACKET 
SEE  ALIAS 
SEE  ALIAS 


CALLED-HOST-SUPERVISORY-PACKET 

NONE 

CALLED-HOST-SUPERVISORY-PACKET  = 
[HOST-RR  |  HOST-RNR  I  HOST-REJ] 
CALLED  NODE  PROTOCOL  LAYER 


CALLED-HOST- TO-CALLED-NODE-LEVEL-3 -PACKET 
CALLED-HOST-LEVEL-3 -PACKET 
CALLED-HOST-TO-CALLED-NODE-LEVEL-3-PACKET= 
[CALL-ACCEPTED-PACKET  |  WINDOWED-CALLEL- 
HOST-TO-CALLING-HOST-DATA-PACKET  !  CALLED 
flOST- INTERRUPT- PACKET  |  CALLED-HOST-CLEAR 
REQUEST  |  CALLED-HOST-RESET-REQUEST  | 
CALLED-HOST-RESTART-REQUEST  |  CALLED-HOST 
SUPERVISORY-PACKET] 

OVERVIEW  LAYER 
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DATAFLOW  NAME: 

ALIASES: 

COMPOSITION: 


NOTES: 


DATA  ELEMENT  NAME: 
ALIASES: 

VALUES  AND  MEANINGS: 


NOTES: 


DATAFLOW  NAME: 

ALIASES: 

COMPOSITION: 


NOTES: 


DATA  ELEMENT  NAME: 
ALIASES: 

VALUES  AND  MEANINGS: 


NOTES: 


DATAFLOW  NAME: 

ALIASES: 

COMPOSITION: 


NOTES: 


CALLED-HOST-TO-CALLING-HOST-BUFFEF.ED- 

SEQUENCE 

NONE 

CALLED-HOST-TO-CALLING-HOST-BUFFERED- 
SEQUENCE  =  { CALLED-HOST-TO-CALLING-HOST- 
DATA-PACKET} 

CALLING  HOST  PROTOCOL  LAYER 


CALLED-HOST-TO-CALLING-HOST-DATA 

NONE 

ANY  STRING  OF  BITS  NEEDING  TO  BE  TRANS¬ 
MITTED  FROM  THE  CALLED  HOST  TO  THE 
CALLING  HOST 
OVERVIEW  LAYER 


CALLED-HOST-TO-CALLING-HOST-DATA- 

PACKET 

NONE 

CALLED-HOST-TO-CALLING-HOST-DATA- 
PACKET  =  [  CALLED-HOST-TO-CALLING-IIOST- 
CATEGORY-1 -PACKET  I  CALLED-HOST-TO- 
CALLING-HOST-CATEGORY-2-PACKET] 

CALLED  HOST  PROTOCOL  LAYER 


CALLED-HOST-TO-CALLING-HOST- INTERRUPT- 
DATA 
NONE 

ANY  DATA  THAT  MUST  BE  TRANSMITTED  FROM 
THE  CALLED  HOST  TO  THE  CALLING  HOST 
WITHOUT  USING  THE  LEVEL  3  FLOW  CONTROL 
THE  DATA  MUST  NOT  BE  MORE  THAN  8  BITS 
IN  LENGTH 

CALLED  HOST  PROTOCOL  LAYER 


CALLED-HOST-TO-CALLING-HOST-PACKET 

NONE 

CALLED-HOST-TO-CALLING-HOST-PACKET  = 
[CALLING-NODE-INTERRUPT-PACKET  |  CALL- 
CONNECTED-PACKET  |  CALLING-NODE- 
WINDOWED-CALLED-HOST-TO-CALLING-HOST- 
DAT A— PACKET] 

CALLING  NODE  PROTOCOL  LAYER 


183 


DATA  ELEMENT  NAME: 
ALIASES: 

VALUES  AND  MEANINGS: 
NOTES: 


DATAFLOW  NAME: 

ALIASES: 

COMPOSITION: 


NOTES: 


DATA  ELEMENT  NAME: 
ALIASES: 

VALUES  AND  MEANINGS: 
NOTES: 


DATA  ELEMENT  NAME: 
ALIASES: 

VALUES  AND  MEANINGS: 


NOTES : 


DATAFLOW  NAME: 
ALIASES: 

COMPOSITION: 

NOTES: 


DATA  ELEMENT  NAME: 
ALIASES: 

VALUES  AND  MEANINGS: 
NOTES : 


CALLED-NODE-CLEAR-CONFIRMATION-PACKET 

NONE 

OCTET  3=(00010111) 

CALLED  NODE  AND  HOST  PROTOCOL  LAYERS 


CALLED-NODE-CONFIRMATION-PACKET 

NONE 

CALLED-NODE-CONFIRMATION-PACKET  = 

[ CALLED -NODE- INTERRUPT-CONF I RMATION- 
PACKET  |  CALLED-NODE-CLEAR- 
CONFIRMATION-PACKET  |  CALLED-NODE- 
RESET-CONFIRMATION-PACKET  |  CALLED- 
NODE-RESTART-CONFIRMATION-PACKET] 
CALLED  NODE  PROTOCOL  LAYER 


CALLED-NODE -INTERRUPT-CONF IRMATION- 
PACKET 
NONE 

OCTET  3=(001D0111) 

CALLED  NODE  AND  HOST  PROTOCOL  LAYERS 


CALLED-NODE-INTERRUPT-PACKET 

NONE 

CONTAINS  UP  TO  8  BITS  OF  DATA  FROM  THE 
CALLING  HOST  TO  THE  CALLED  HOST  THAT 
DOES  NOT  HAVE  TO  BE  TRANSMITTED  USING 
THE  LEVEL  3  FLOW  CONTROL 
CALLED  NODE  PROTOCOL  LAYER 


CALLED-NODE-LEVEL-3 -PACKET 
CALLED-NODE -TO-CALLING-NODE-LEVEL-3- 
PACKET 
SEE  ALIAS 
SEE  ALIAS 


CALLED -NODE- RESET-CONFIRMATION-PACKET 
NONE 

OCTET  3=(00011111) 

CALLED  HOST  AND  NODE  PROTOCOL  LAYERS 
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DATA  ELEMENT  NAME:  CALLED-NODE-RESTART-CONFIRMATION-PACKET 

ALIASES:  NONE 

VALUES  AND  MEANINGS:  OCTET  3=(11111111) 

NOTES:  CALLED  NODE  AND  HOST  PROTOCOL  LAYERS 


DATAFLOW  NAME: 

ALIASES: 

COMPOSITION: 

NOTES : 


CALLED-NODE-SUPERVISORY-PACKET 

NONE 

CALLED-NODE-SUPERVISORY-PACKET  = 
[NODE-RR  !  NODE-RNR  |  NODE-REJ]  +  P(R) 
CALLED  NODE  AND  HOST  PROTOCOLS 


DATAFLOW  NAME:  CALLED-NODE-TO-CALLED-HOST-LEVEL-3 -PACKET 

ALIASES:  NONE 

COMPOSITION:  CALLED-NODE-TO-CALLED-HOST-LEVEL-3-PACKET= 

[NODE-CALL-MAINTENANCE-PACKET  |  CALLED- 
NODE-SUPERVISORY-PACKET  |  TRANSMITTED- 
CALLING-HOST-TO-CALLED-HOST-DATA-PACKET  I 
TRAN SMI TTED-CALLING-HOST-TO-CALLED-HOST- 
NODE- INTERRUPT-PACKET] 

NOTES:  OVERVIEW  LAYER 


DATAFLOW  NAME:  CALLED-NODE-TO-CALLING-NODE-LEVEL-3 -PACKET 

ALIASES:  CALLED-NODE-LEVEL-3 -PACKET 

COMPOSITION :  CALLED-NODE-TO-CALLING-NODE-LEVEL-3 -PACKET 

[CALLED-NODE-INTERRUPT-PACKET  |  CALL- 
ACCEPTED-PACKET  |  CALLED-HOST-TO-CALLING- 
HOST-DATA-PACKET] 

NOTES:  OVERVIEW  LAYER 


DATAFLOW  NAME:  CALLED-NODE-WINDOWED-CALLING-HOST-TO- 

CALLED-HOST-DATA-PACKET 

ALIASES:  TRAN  SMITTED-CALLING-HOST-TO-CALLED- 

HOST-DATA-PACKET 
COMPOSITION:  SEE  ALIAS 

NOTES:  SEE  ALIAS 


DATAFLOW  NAME: 
ALIASES: 

VALUES  AND  MEANINGS: 
NOTES: 


CALLING-HOST-CONFIRMATION-PACKET 
CALLING-HOST-INTERRUPT-CONFIRMATION- 
PACKET 
SEE  ALIAS 
SEE  ALIAS 
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DATA  ELEMENT  NAME: 
ALIASES: 

VALUES  AND  MEANINGS: 
NOTES: 


DATAFLOW  NAME: 

ALIASES: 

COMPOSITION: 


NOTES: 


DATAFLOW  NAME: 

ALIASES: 

COMPOSITION: 

NOTES: 


DATAFLOW  NAME: 

ALIASES: 

COMPOSITION: 


NOTES: 


DATA  ELEMENT  NAME: 
ALIASES: 

VALUES  AND  MEANINGS: 


NOTES: 


DATAFLOW  NAME: 

ALIASES: 

COMPOSITION: 


NOTES: 


CALLING-HOST- INTERRUPT-CONFIRMATION-PACKET 

CALLING-HOST-CONFIRMATION-PACKET 

OCTET  3  =  (001001II) 

CALLING,  CALLED  HOST  AND  NODE  PROTOCOL 
LAYERS 


CALLING-HOST-LEVEL-3 -PACKET 
CALLING-HOST-TO-CALLING-NODE-LEVEL-3 -PACKET 
CALLING-HOST-LEVEL-3-PACKET= 
[HOST-CALL-SETUP-PACKET  |  WINDOWED-CALL ING¬ 
HOST-TO-CALLED  -HOST-DATA-  PACKET  |  CALLING- 
HOST-  INTERRUPT-CONFIRMATION-PACKETI 
OVERVIEW  LAYER 


CALLING-HOST-SUPERVISORY-PACKET 

NONE 

CALLING-HOST-SUPERVISORY-PACKET  = 
[HOST-RR  |  HOST-RNR  |  HOST-REJ] 
CALLING  NODE  PROTOCOL  LAYER 


CALLING-HOST-TO-CALLED-HOST-BUFFERED- 

SEQUENCE 

NONE 

CALLING-HOST-TO-CALLED-HOST-BUFFERED- 
SEQUENCE  =  { CALLED-HOST-TO-CALLING- 
HOST-DATA- PACKET} 

CALLED  HOST  PROTOCOL  LAYER 


CALLING-HOST-TO-CALLED-HOST-DATA 

NONE 

ANY  STRING  OF  BITS  NEEDING  TO  BE  TRANS¬ 
MITTED  FROM  THE  CALLING  HOST  TO  THE  CALLED 
HOST 

OVERVIEW  LAYER 


CALLING-HOST-TO-CALLED-HOST-DATA-PACKET 

NONE 

CALLING-HOST-TO-CALLED-HOST-DATA-FACKET  = 
[ CALLING-HOST-TO-CALLED-HOST-CATEGORY -1 - 
PACKET  |  CALLING-HOST-TO-CALLED-HOST- 
CATEGORY- 2 -PACKET] 

CALLING  HOST  PROTOCOL  LAYER 


186 


DATA  ELEMENT  NAME: 
ALIASES: 

VALUES  AND  MEANINGS: 


NOTES: 


DATAFLOW  NAME: 

ALIASES: 

COMPOSITION: 


NOTES: 


DATAFLOW  NAME: 
ALIASES: 
COMPOSITION: 
NOTES: 


DATA  ELEMENT  NAME: 
ALIASES: 

VALUES  AND  MEANINGS: 
NOTES: 


DATA  ELEMENT  NAME: 
ALIASES: 

VALUES  AND  MEANINGS: 
NOTES: 


DATAFLOW  NAME: 

ALIASES: 

COMPOSITION: 


NOTES: 


DATA  ELEMENT  NAME: 
ALIASES: 

VALUES  AND  MEANINGS: 
NOTES: 


CALLING-HOST-TO-CALLED-HOST- INTERRUPT-DATA 
NONE 

ANY  DATA  THAT  MUST  BE  TRANSMITTED 
BETWEEN  HOSTS  WITHOUT  USING  THE  FLOW 
CONTROL  MECHANISM.  DATA  LENGTH  MUST 
BE  LESS  THAN  OR  EQUAL  TO  8  BITS. 

CALLING  HOST  PROTOCOL  LAYER 


CALLING-HOST-TO-CALLED-HOST- PACKET 
NONE 

CALLING-HOST-TO-CALLED-HOST- PACKET  = 
[CALLED-NODE- INTERRUPT-PACKET  | 
INCOMING-CALL-PACKET  |  CALLED-NODE- 
WINDOWED-CALLING-HOST-TO-CALLED-HOST- 
DATA-PACKET  |  CALLED-NODE- 
SU PE RVISORY- PACKET] 

CALLED  NODE  PROTOCOL  LAYER 


CALLING- HOST- TO-CALLING-NODE-LEVEL-3 -PACKET 
CALLING-HOST-LEVEL-3 -PACKET 
SEE  ALIAS 
SEE  ALIAS 


CALLING-NODE-CLEAR-CONFIRMATION-PACKET 

NONE 

OCTET  3=  (00010111) 

CALLING  NODE  AND  HOST  PROTOCOL  LAYERS 


CALLING- NODE-CLEAR- INDICATION -PACKET 
NONE 

OCTET  3  =  (00010011) 

CALLING  NODE  PROTOCOL  LAYER 


CALLING-NODE-CONFIRMATION-PACKET 

NONE 

CALLING-NODE-CONFIRMATION-PACKET  = 
[CALLING-NODE- INTERRUPT- CONFIRMATION- 
PACKET  |  CALLING-NODE-CLEAR- 
CONFIRMATION -PACKET  |  CALLING-NODE¬ 
RESET-CONFIRMATION-PACKET  |  CALLING- 
NODE-RESTART-CONFIRMATION-PACKET] 
CALLING  NODE  PROTOCOL  LAYER 


CALLING-NODE- INTERRUPT-CONFIRMATION- 
PACKET 
NONE 

OCTET  3  =  (0  0  1  O  0  1  1  1) 

CALLING  HOST  AND  NODE  PROTOCOL  LAYERS 
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DATA  ELEMENT  NAME: 
ALIASES: 

VALUES  AND  MEANINGS: 


NOTES: 


DATAFLOW  NAME: 
ALIASES: 

COMPOSITION: 

NOTES: 


DATA  ELEMENT  NAME: 
ALIASES: 

VALUES  AND  MEANINGS: 
NOTES: 


DATA  ELEMENT  NAME: 
ALIASES: 

VALUES  AND  MEANINGS: 
NOTES: 


DATAFLOW  NAME: 

ALIASES: 

COMPOSITION: 

NOTES: 


DATAFLOW  NAME: 

ALIASES: 

COMPOSITION: 


NOTES: 


CALLING-NODE-INTERRUPT-PACKET 

NONE 

CONTAINS  UP  TO  8  BITS  OF  DATA  FROM  THE 
CALLED  HOST  TO  THE  CALLING  HOST  THAT 
DOES  NOT  HAVE  TO  BE  TRANSMITTED  USING 
THE  LEVEL  3  FLOW  CONTROL 
CALLING  NODE  PROTOCOL  LAYER 


CALLING-NODE-LEVEL-3 -PACKET 
CALLING-NODE-TO-CALLED-NODE-LEVEL-3- 
PACKET 
SEE  ALIAS 
SEE  ALIAS 


CALLING-NODE-RESET-CONFIRMATION-PACKET 

NONE 

OCTET  3=(0001I111) 

CALLING  NODE  AND  HOST  PROTOCOL  LAYERS 


CALLING-NODE-RESTART-CONFIRMATION-PACKET 

NONE 

OCTET  3  =  (1  1  1  1  1  1  1  1) 

CALLING  HOST  AND  NODE  PROTOCOL  LAYERS 


CALLING-NODE-SUPERVISORY-PACKET 

NONE 

CALLING-NODE-SUPERVISORY-PACKET  = 
[NODE-RR  |  NODE-RNR  |  NODE-REJ]  +  P(R) 
CALLING  HOST  PROTOCOL  LAYER 


CALLING-NODE -TO-CALLED-NODE-LEVEL-3 -PACKET 
CALLING-NODE-LEVEL-3-PACKET 
CALLING-NODE-TO-CALLED-NODE-LEVEL-3 -PACKET 
[CALLING-NODE-INTERRUPT-PACKET  |  INCOMING- 
CALL-PACKET  !  CALLING-HOST-TO-CALLED-HOST 
DATA-PACKET] 

OVERVIEW  LAYER 


188 


DATAFLOW  NAME: 

ALIASES: 

COMPOSITION: 


NOTES: 


CALLING-NODE-TO-CALLED-NODE-PACKET 

NONE 

CALLING-NODE-TO-CALLED-NODE-PACKET= 
[CALLING-NODE- INTERRUPT-PACKET  | 
INCOMING-CALL-PACKET  |  CALLING-HOST- 
TO-CALLED  -HOST-DATA-  PACKET] 

CALLING  NODE  PROTOCOL  LAYER 


DATAFLOW  NAME: 

ALIASES: 

COMPOSITION: 


NOTES: 


CALLING-NODE-TO-CALLING-HOST-LEVEL-3 -PACKET 
NONE 

CALL ING-NODE-TO-CALLING-HOST-LEVEL-3 -PACKET 
[CALLING-NODE-CONFIRMATION-PACKET  |  CALLED- 
HOST-CALLING-HOST- PACKET  |  ERROR-RECOVERY- 
PACKET] 

OVERVIEW  LAYER 


DATAFLOW  NAME: 

ALIASES: 

COMPOSITION: 

NOTES: 


CALLING-NODE-WINDOWED-CALLED-HOST-TO- 
CALLING-HOST-DATA-PACKET 
TRANSMITTED-CALLED-HOST-TO-CALLING- 
HOST-DATA- PACKET 
SEE  ALIAS 
SEE  ALIAS 


DATAFLOW  NAME: 

ALIASES: 

COMPOSITION: 


DATA 

NONE 

DA TA=[ CALLING-HOST- TO-CALLED-HOST-DATA 
ICALLED-HOST-TO-CALLING-HOST-DATA] 


NOTES : 


CONTEXT  LAYER 


DATA  ELEMENT  NAME: 
ALIASES: 

VALUES  AND  MEANINGS: 
NOTES: 


ERROR-RECOVERY-PACKET 
RESTART- INDICATION-PACKET 
SEE  ALIAS 
SEE  ALIAS 


DATAFLOW  NAME: 

ALIASES: 

COMPOSITION: 


NOTES: 


HOST-CALL-MAINTENANCE-PACKET 

NONE 

HOST-CALL-MAINTENANCE-PACKET  = 
[CALL-ACCEPTED-PACKET  I  RESET-REQUEST- 
PACKET  |  RESTART-REQUEST-PACKET  | 
CLEAR-REQUEST-PACKET] 

CALLED  HOST  PROTOCOL  LAYER 
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DATAFLOW  NAME: 

ALIASES: 

COMPOSITION: 


NOTES: 


DATA  ELEMENT  NAME: 
ALIASES: 

VALUES  AND  MEANINGS: 
NOTES : 


DATA  ELEMENT  NAME: 
ALIASES: 

VALUES  AND  MEANINGS: 
NOTES: 


DATA  ELEMENT  NAME: 
ALIASES: 

VALUES  AND  MEANINGS: 
NOTES: 


DATA  ELEMENT  NAME: 
ALIASES: 

VALUES  AND  MEANINGS: 
NOTES: 


DATA  ELEMENT  NAME: 
ALIASES: 

VALUES  AND  MEANINGS: 
NOTES: 


DATA  ELEMENT  NAME: 
ALIASES: 

VALUES  AND  MEANINGS: 


NOTES: 


HOST-CALL-SETUP- PACKET 
NONE 

HOST-CALL-SETUP-PACKET  =  [CALL-REQUEST- 
PACKET  |  RESET-REQUEST-PACKET  |  RESTART- 
REQUEST-PACKET  |  CLEAR-REQUEST-PACKET] 
CALLING  HOST  PROTOCOL  LAYER 


HOST-REJ 

NONE 

OCTET  3  =  (XXX01001) 

CALLING,  CALLED  HOST  PROTOCOL  LAYERS 


HOST-RNR 

NONE 

OCTET  3  =  (XXX00101) 

CALLING,  CALLED  HOST  PROTOCOL  LAYERS 


HOST-RR 

NONE 

OCTET  3  =  (XXX00001) 

CALLING,  CALLED  HOST  PROTOCOL  LAYERS 


INCOMING-CALL- PACKET 
NONE 

OCTET  3=  (00001011) 

CALLING,  CALLED  NODE  PROTOCOL  LAYERS 


LAST-PACKET-BIT 

NONE 

BIT  5  OF  OCTET  3  IS  SET  TO  0 
CALLING,  CALLED  HOST  PROTOCOL  LAYERS 


LOCAL-PROCEDURE-ERROR 

NONE 

AN  ERROR  CAN  BE  CAUSED  BY  AN  INVALID 
CALL ING-HOST-LEVEL-3 -PACKET  OR  AN 
INVALID  CALLED-NODE-LEVEL-3- PACKET 
ALSO,  ERRORS  CAN  OCCUR  WHEN  THE 
PACKET  RECEIVED  IS  ILLEGAL  FOR  THE 
CURRENT  STATE  OF  THE  CALLING  NODE 
CALLING  NODE  PRTOCOL  LAYER 
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DATA  ELEMENT  NAME: 
ALIASES: 

VALUES  AND  MEANINGS: 
NOTES: 


DATAFLOW  NAME: 

ALIASES: 

COMPOSITION: 


NOTES: 


DATAFLOW  NAME: 

ALIASES: 

COMPOSITION: 


NOTES: 


DATA  ELEMENT  NAME: 
ALIASES: 

VALUES  AND  MEANINGS: 
NOTES: 


DATA  ELEMENT  NAME: 
ALIASES: 

VALUES  AND  MEANINGS: 


MORE-DATA-BIT 

NONE 

BIT  5  OF  OCTET  3  IS  SET  TO  1 
CALLING,  CALLED  HOST  PROTOCOL  LAYERS 


NODE-CALL-MAINTENANCE-PACKET 

NONE 

NODE-CALL-MAINTENANCE-PACKET  = 
[RELAYED-INCOMING-CALL-PACKET  | 
CALLED-NODE-CLEAR-INDI CATION-PACKET | 
CALLED-NODE-RESET- INDICATION-PACKET | 
CALLED-NODE-RESTART-INDI CATION-PACKET | 
CALLED-NODE-CLEAR-CONF I RM ATI ON-PACKET | 
CALL ED -NODE -RE SET-CONFIRMATION- PACKET | 
CALLED-NODE-RESTART-CONFIRMATION- 
PACKET  |  CALLED-NODE-INTERRUPT- 
CONFIRMATION-PACKET] 

CALLED  HOST  PROTOCOL  LAYER 


NODE-CALL-SETUP-PACKET 

NONE 

NODE-CALL-SETUP-PACKET  = 
[CALL-CONNECTED-PACKET  I  NODE-CLEAR- 
INDICATION-PACKET  I  CALLING-NODE- 
CLEAR-CONFIRMATION-PACKET  I  CALLING- 
NODE-RESET-CONFIRMATION-PACKET  | 
CALLING-NODE-RESTART-CONFIRMATION- 
PACKET  |  CALLING-NODE-RESET- 
INDICATION-PACKET  |  CALLING-NODE¬ 
RESTART-INDICATION-PACKET] 

CALLING  HOST  PROTOCOL  LAYER 


NODE- INTERRUPT- IDENTIFIER 
NONE 

OCTET  3  =  (00100011) 

CALLING,  CALLED  HOST  PROTOCOL  LAYERS 


PROCEDURE  ERROR 
NONE 

AN  ERROR  CAN  BE  CAUSED  BY  AN  INVALID 
CALLED-HOST-LEVEL- 3 -PACKET  OR  AN 
INVALID  CALLING-NODE-LEVEL-3 -PACKET. 
ALSO,  ERRORS  CAN  OCCUR  WHEN  THE 
PACKET  RECEIVED  IS  ILLEGAL  FOR  THE 
CURRENT  STATE  OF  THE  CALLED  NODE. 
CALLED  NODE  PROTOCOL  LAYER 


NOTES: 


DATA  ELEMENT  NAME: 
ALIASES: 

VALUES  AND  MEANINGS: 
NOTES: 


P(R) 

PACKET-RECEIVE-NUMBER 

BITS  8,7,6  OF  OCTET  3  IN  DATA  AND 

SUPERVISORY  PACKETS 

CALLING,  CALLED  NODE  AND  HOST  PROTOCOLS 


DATA  ELEMENT  NAME: 
ALIASES: 

VALUES  AND  MEANINGS: 
NOTES: 


P(S) 

PACKET-SEND-NUMBER 

BITS  4,3,2  OF  OCTET  3  IN  DATA  AND 

SUPERVISORY  PACKETS 

CALLING,  CALLED  NODE  AND  HOST  PROTOCOLS 


DATA  ELEMENT  NAME: 
ALIASES: 

VALUES  AND  MEANINGS: 


NOTES: 


QUEUED-CALLED-HOST-TO-CALLING- HOST- 
DATA-  PACKET 
NONE 

THIS  IS  A  CALLED -HOST-TO-CALLING -HOST- 
DATA-  PACKET  THAT  HAS  BEEN  PLACED  IN 
THE  TRANSMISSION  QUEUE  TO  BE  SENT  TO 
THE  CALLED  NODE 
CALLED  HOST  PROTOCOL  LAYER 


DATA  ELEMENT  NAME: 
ALIASES: 

VALUES  AND  MEANINGS: 


NOTES: 


QUEUED-CALL ING-HO ST-TO-CALLED -HOST-DA TA- 
PACKET 
NONE 

THIS  IS  A  CALLING -HO ST-TO-CAL LED -HO ST-DATA- 
PACKET  THAT  HAS  BEEN  PLACED  IN  THE 
TRANSMISSION  QUEUE  TO  BE  SENT  TO  THE 
CALLING  NODE 

CALLING  HOST  PROTOCOL  LAYER 


DATA  ELEMENT  NAME: 
ALIASES: 

VALUES  AND  MEANINGS: 
NOTES: 


RECEIVED-CALL-ACCEPTED-PACKET 

NONE 

OCTET  3  =  (00001111) 

CALLING,  CALLED  NODE  PROTOCOL  LAYERS 


DATA  ELEMENT  NAME: 
ALIASES: 

VALUES  AND  MEANINGS: 
NOTES : 


PECE IVED-CALL- REQUEST- PACKET 
NONE 

OCTET  3  =  (00001  01  1) 

CALLING  HOST  AND  NODE  PROTOCOL  LAYERS 
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DATA  ELEMENT  NAME: 
ALIASES: 

VALUES  AND  MEANINGS: 
NOTES: 


DATA  ELEMENT  NAME: 
ALIASES: 

VALUES  AND  MEANINGS: 


NOTES: 


DATA  ELEMENT  NAME: 
ALIASES: 

VALUES  AND  MEANINGS: 
NOTES: 


DATA  ELEMENT  NAME: 
ALIASES: 

VALUES  AND  MEANINGS: 
NOTES: 


DATA  ELEMENT  NAME: 
ALIASES: 

VALUES  AND  MEANINGS: 
NOTES: 


DATA  ELEMENT  NAME: 
ALIASES: 

VALUES  AND  MEANINGS: 


RECEIVED-CAT, T  PD  uuST-CLEAR -REQUEST 

OCTET  3=  (00010011) 

CALLED  NODE  AND  HOST  PROTOCOL  LAYERS 


RECEIVED -CALLED-HOST- INTERRUPT-PACKET 
NONE 

ANY  STRING  OF  UP  TO  8  BITS  THAT  IS 
TRANSMITTED  FROM  THE  CALLED  HOST  TO 
THE  CALLING  HOST  WITHOUT  USING  LEVEL 
3  FLOW  CONTROL 
CALLING  NODE  PROTOCOL  LAYER 


RECE IVED-CALLED-HOST-RESET-REQUEST 
NONE 

OCTET  3=  (00011011) 

CALLED  NODE  AND  HOST  PROTOCOL  LAYERS 


RECE IVED -CALLED-HOST- RE START-REQUEST 
NONE 

OCTET  3=  (11111011) 

CALLED  HOST  AND  NODE  PROTOCOL  LAYERS 


FECEIVED-CALLED-HOST-TO-CALLING-HCST- 

DATA-PACKET 

NONE 

UP  TO  128  BYTES  OF  DATA  FROM  THE 
CALLED  HOST  TO  THE  CALLING  HOST 
CALLING  NODE  PROTOCOL  LAYER 


RECE IVED-CALLED-NODE- INTERRUPT-PACKET 
NONE 

OCTET  3  =  (00100011) 

INTERRUPT  DATA  IS  ANY  STRING  OF  UP  TO 
8  BITS  THAT  IS  TRANSMITTED  FROM  THE 
CALLED  HOST  TO  THE  CALLING  HOST 
CALLING  NODE  PROTOCOL  LAYER 


NOTES: 


DATA  ELEMENT  NAME: 
ALIASES: 

VALUES  AND  MEANINGS: 
NOTES: 


DATA  ELEMENT  NAME: 
ALIASES: 

VALUES  AND  MEANINGS: 


NOTES : 


DATA  ELEMENT  NAME: 
ALIASES: 

VALUES  AND  MEANINGS: 
NOTES: 


DATA  ELEMENT  NAME: 
ALIASES: 

VALUES  AND  MEANINGS: 
NOTES: 


DATA  ELEMENT  NAME: 
ALIASES: 

VALUES  AND  MEANINGS: 
NOTES: 


DATA  ELEMENT  NAME: 
ALIASES: 

VALUES  AND  MEANINGS: 
NOTES: 


DATA  ELEMENT  NAME: 
ALIASES: 

VALUES  AND  MEANINGS: 
NOTES: 


RECEIVED-CALLING-HOST-CLEAR-REQUEST- 

PACKET 

NONE 

OCTET  3=(00010011) 

CALLING  HOST  AND  NODE  LAYERS 


RECEIVED-CALLING-HOST-INTERRUPT-PACKET 

NONE 

ANY  STRING  OF  UP  TO  8  BITS  THAT  IS 
TRANSMITTED  FROM  THE  CALLING  HOST  TO 
THE  CALLED  HOST  WITHOUT  USING  LEVEL 
3  FLOW  CONTROL 
CALLING  NODE  PROTOCOL  LAYER 


RECEIVED-CALLING-HOST-RESE^-REQUEST 

NONE 

OCTET  3=  (00011011) 

CALLING  HOST  AND  NODE  PROTOCOL  LAYERS 


RECEIVED-CALLING-HOST-RESTART-REQUEST- 

PACKET 

NONE 

OCTET  3a(11111011) 

CALLING  HOST  AND  NODE  PROTOCOL  LAYERS 


RECEIVED-CALLING-HOST-TO-CALLED-HOST- 

DATA-PACKET 

NONE 

UP  TO  128  BYTES  OF  DATA  FROM  THE 
CALLING  HOST  TO  THE  CALLED  HOST 
CALLED  NODE  PROTOCOL  LAYER 


RECEIVED-CALLING-NODE-INTERRUPT-PACKET 

NONE 

OCTET  3  =(001  00011) 

CALLED  NODE  PROTOCOL  LAYER 


RECEIVED-INCOMING-CALL-PACKET 

NONE 

OCTET  3=(00001011) 
CALLED  NODE  PROTOCOL  LAYER 
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DATAFLOW  NAME: 

ALIASES: 

COMPOSITION: 


NOTES: 


DATAFLOW  NAME: 

ALIASES: 

COMPOSITION: 


NOTES: 


DATA  ELEMENT  NAME: 
ALIASES: 

VALUES  AND  MEANINGS: 
NOTES: 


DATA  ELEMENT  NAME: 
ALIASES: 

VALUES  AND  MEANINGS: 
NOTES : 


DATA  ELEMENT  NAME: 
ALIASES: 

VALUES  AND  MEANINGS: 
NOTES: 


DATAFLOW  NAME: 
ALIASES: 

COMPOSITION: 

NOTES: 


RECEIVED-WINDOWED-CALLED-HOST-TO- 
CALLING-HOST-DATA- PACKET 
NONE 

RECEIVED-WINDOWED-CALLED-HOST-TO- 
CALLING-HOST-DATA-PACKET  =  P(R)  +  P(S) 
+  CALLED-HOST-TO-CALLING-HGST-DATA 
CALLED  NODE  PROTOCOL  LAYER 


RECE IVED-WINDOWED-CALLING-HOST-TO- 
CALLED-HOST-DATA-PACKET 
NONE 

RECE I VED-WINDOWED -CALL ING- HOST- TO- 
CALLED  -HOST-DA  TA-PACKET  = 

P ( R)  +  P(S)  +  CALLING-HOST-TO-CALLED- 
HOST-DATA 

CALLING  NODE  PROTOCOL  LAYER 


RELAYED-CALL-ACCEPTANCE-PACKET 

NONE 

OCTET  3=  (00001111) 
CALLED  NODE  PROTOCOL  LAYER 


RELAYED-INCOMING-CALL-PACKET 

NONE 

OCTET  3=(00001011) 

CALLED  NODE  AND  HOST  PROTOCOL  LAYERS 


RESTART-INDICATION-PACKET 
ERROR-RECOVERY-PACKET 
OCTET  3=(  11111011) 
CALLING  HOST  AND  NODE  LAYER 


ROUTED-CALLED-NODE-PACKET 
ROUTED -CALLED-NODE-TO-CALL ING-NODE- 
LEVEL-3 -PACKET 
SEE  ALIAS 
SEE  ALIAS 
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DATAFLOW  NAME: 

ALIASES: 

COMPOSITION: 


NOTES: 


routed-called-node-to-calling-node-level- 

3-PACKET 

ROUTED-CALLED-NODE-PACKET 
ROUTED-CALLED-NODE-TO-CALLING-NODE-LEVEL- 
3 -PACKET  =  l RECEIVED-CALLED-NODE- 
INTERRUPT- PACKET  |  RECEIVED-CALL-ACCEPTED- 
PACKET  |  RECE I VED-CALLED-HOST-TO-CALL ING¬ 
HOST-DA  TA-PACKET] 

OVERVIEW  LAYER 


DATAFLOW  NAME: 
ALIASES: 

COMPOSITION: 

NOTES: 


ROUTED-CALLING-NODE-PACKET 
ROUTED-CALLING-NODE-TO-CALLED-NODE- 
LEVEL -3 -PACKET 
SEE  ALIAS 
SEE  ALIAS 


DATAFLOW  NAME: 

ALIASES: 

COMPOSITION: 


NOTES: 


ROUTED-CALLING-NODE-TO-CALLED-NODE-LEVEL- 

3-PACKET 

ROUTED-CALLING-NODE-PACKET 
ROUTED-CALLING-NODE-TO-CALLED-NODE-LEVEL- 
3-PACKET  =  (RECEIVED-CALLING-NODE-LEVEL- 
3-PACKET  |  RECEIVED-INCOMING-CALL-PACKET  I 
RECE IVED-CALLING-HOST-TO-CALLED-HOST-DA TA- 
PACKET] 

OVERVIEW  LAYER 


DATAFLOW  NAME: 

ALIASES: 

COMPOSITION: 


NOTES: 


TRANSMITTED-CALLED-HOST-TO-CALLING-HOST- 
CATEOORY-l -PACKET 
NONE 

TRAN SMI TTED-CALLED-HOST-TO-CALL ING-HOST- 
CATEGORY-1 -PACKET  =  LAST-PACKET-BIT  + 
CALLED-HOST-TO-CALLING-HOST-DA TA-PACKET 
CALLING  HOST  PROTOCOL  LAYER 


DATAFLOW  NAME: 

ALIASES: 

COMPOSITION: 

NOTES: 


TRANSMITTED-CALLED-HOST-TO-CALLING-HOST- 
CATEGORY- 2 -PACKET 
NONE 

TRANSMITTED-CALLED-HOST-TO-CALLING-HOST- 
CATEGORY- 2 -PACKET  =  MORE-DA TA-BIT  + 
CALLED-HOST-TO-CALLING-HOST-DA TA-PACKET 
CALLING  HOST  PROTOCOL  LAYER 
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DATAFLOW  NAME: 

ALIASES: 

COMPOSITION: 


NOTES: 


TRANSMITTED-CALLED-HOST-TO-CALLING-HOST- 

COMPLETE-PACKET-SEQUENCE 

NONE 

TRANSMITTED-CALLED-HOST-TO-CALLING-HOST- 
COMPLETE-PACKET-SEQUENCE  =  CALLED-HOST-TO- 
CALLING-HOST-BUFFERED-SEQUENCE  + 
TRANSMITTED-CALLED-HOST-TO-CALLING-HOST- 
CATEGORY-1 -PACKET 
CALLING  HOST  PROTOCOL  LAYER 


DATA  ELEMENT  NAME: 
ALIASES: 

VALUES  AND  MEANINGS: 


NOTES: 


TRANSMITTED-CALLED-HOST-TO-CALLING-HOST- 

DATA 

NONE 

ANY  STRING  OF  BITS  THAT  HAS  BEEN  TRANS¬ 
MITTED  FROM  THE  CALLED  HOST  TO  THE 
CALLING  HOST 
OVERVIEW  LAYER 


DATAFLOW  NAME: 

ALIASES: 

COMPOSITION: 


NOTES: 


TRANSMITTED-CALLED-HOST-TO-CALLING-HOST- 

DATA-PACKET 

NONE 

TRANSMITTED-CALLED-HOST-TO-CALLING-HOST- 
DATA-PACKET  =  [ TRAN SMITTED-CALLED-HOST-TO- 
CALLING-HOST-CATEGORY-I -PACKET  | 
TRANSMITTED-CALLED-HOST-TO-CALLING-HOST- 
CATEGORY-2-PACKET] 

CALLING  HOST  PROTOCOL  LAYER 


DATA  ELEMENT  NAME: 
ALIASES: 

VALUES  AND  MEANINGS: 


NOTES: 


TRAN  SM ITTED-CALLED-HOST-TO-CALL ING-HOST- 
INTERRUPT-DATA 
NONE 

ANY  STRING  OF  8  BITS  THAT  HAS  BEEN 
TRANSMITTED  FROM  THE  CALLED  HOST  TO 
THE  CALLING  HOST  WITHOUT  USING  THE 
LEVEL  3  FLOW  CONTROL  MECHANISM 
CALLING  HOST  PROTOCOL  LAYER 


DATAFLOW  NAME: 

ALIASES: 

COMPOSITION: 


NOTES : 


TRAN SM ITTED-CALLED-HOST-TO-CALL ING- HOST- 
NODE-  INTERRUPT-PACKET 
NONE 

TRANSMITTED-CALLED-HOST-TO-CALLING-IIOST- 
NODE- INTERRUPT- PACKET  =  NODE-INTERRUPT- 
IDENTIFIER  +  TR AN SM ITTED-CALLED-HOST-TO- 
CALL  ING-HOST-  INTERRUPT-DATA 
CALLING  HOST  PROTOCOL  LAYER 
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DATAFLOW  NAME: 

ALIASES: 

COMPOSITION: 

NOTES: 

DATAFLOW  NAME: 

ALIASES: 

COMPOSITION: 

NOTES: 

DATAFLOW  NAME: 

ALIASES: 

COMPOSITION: 

NOTES: 

DATA  ELEMENT  NAME: 
ALIASES: 

VALUES  AND  MEANINGS: 

NOTES: 

DATAFLOW  NAME: 

ALIASES: 

COMPOSITION: 

NOTES: 


TRAN SMITTED-CALL ING- HOST-TO-CALLED- 
HOST-CATEGORY-1 -PACKET 
NONE 

TRANSMITTED-CALLING-HOST-TO-CALLED- 
HOST-CATEGORY-1 -PACKET  =  LAST-PACKET- 
BIT  +  CALLING-HOST-TO-CALLED-HOST- 
DATA- PACKET 

CALLED  HOST  PROTOCOL  LAYER 


TRAN SM ITTED-CALL ING- HOST- TO-CALLED- 
HOST-CATEGORY- 2 -PACKET 
NONE 

TRANSMITTED-CALLING-HOST-TO-CALLED- 
HOST-CATEGORY- 2- PACKET  =  MORE-DATA-BIT 
+  CALLING-HOST-TO-CALLED-HOST-DATA- 
PACKET 

CALLED  HOST  PROTOCOL  LAYER 


TRAN SMITTED-CALL ING-HOST-TO-CALLED- 
HOST-COMPLETE-PACKET-SEQUENCE 
NONE 

TRANSMITTED-CALLING-HOST-TO-CALLED- 
HOST-COMPLETE-PACKET-SEQUENCE  = 
CALLING-HOST-TO-CALLED-HOST-BUFFERED- 
SEQUENCE  +  TRANSMITTED-CALLING-HOST- 
TO-CALLED-HOST-CATEGORY-1 -PACKET 
CALLED  HOST  PROTOCOL  LAYER 


TRANSMITTED-CALLING-HOST-TO-CALLED-HOST- 

DATA 

NONE 

ANY  STRING  OF  BITS  THAT  HAS  BEEN  TRANS¬ 
MITTED  FROM  THE  CALLING  HOST  TO  THE 
CALLED  HOST 
OVERVIEW  LAYER 


TRAN  SMITTED-CALLING-HOST-TO-CALLED- 
HOST-DATA-PACKET 
NONE 

TRAN SMI TTED-CALLING-HOST-TO-CALLED- 
HOST-DATA-PACKET  =  [ TRAN SMITTED- 
CALL  ING-  HOST-TO-CALLED-HOST-CATEGORY- 
1-PACKET  |  TRAN SMI TTED-CALLING-HOST- 
TO-CALLED-HOST-CATEGORY-2-PACKET] 
CALLED  HOST  PROTOCOL  LAYER 
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DATA  ELEMENT  NAME: 

at  T  RQ  RQ  • 

VALUES  AND  MEANINGS: 

NOTES : 

DATAFLOW  NAME: 

ALIASES: 

COMPOSITION: 

NOTES: 

DATAFLOW  NAME: 
ALIASES: 

COMPOSITION: 

NOTES: 

DATAFLOW  NAME: 

ALIASES: 

COMPOSITION: 

NOTES: 

DATAFLOW  NAME: 

ALIASES: 

COMPOSITION: 

NOTES: 


TRAN  SM ITTED-CALLING-HOST-TO-CALLED- 
HOST- INTERRUPT-DATA 
NONE 

ANY  STRING  OF  8  BITS  THAT  HAS  BEEN 
TRANSMITTED  FROM  THE  CALLING  HOST 
TO  THE  CALLED  HOST  WITHOUT  USING 
THE  LEVEL  3  FLOW  CONTROL 
CALLED  HOST  PROTOCOL  LAYER 


TRANSMITTED-CALLING-HOST-TO-CALLED- 

HOST-NODE-INTERRUPT-PACKET 

NONE 

TRANSMITTED-CALLING-HOST-TO-CALLED- 
HOST-NODE- INTERRUPT- PACKET  =  NODE¬ 
INTERRUPT-IDENTIFIER  +  TRAN SMI TTED- 
CALLING-HOST-TO-CALLED-HOST-INTERRUPT- 
DATA 

CALLED  HOST  PROTOCOL  LAYER 


TRANSMITTED-DATA 

NONE 

TRANSMITTED-DATA= 

[TRAN SMITTED-CALLING-HOST-TO-CALLED-HOST- 
DATA  I  TRANSMITTED-CALLED-HOST-TO-CALLING 
HOST-DATA] 

CONTEXT  LAYER 


WINDOWED-CALLED-HOST-TO-CALLING-HOST- 

DATA-PACKET 

NONE 

WINDOWED-CALLED-HOST-TO-CALLING-HOST- 
DATA-PACKET  =  [ CALLED-HOST-TO-CALLING- 
HOST-DATA-PACKET  +  PACKET-SEND-NUMBER 
|  HOST-RR  |  HOST-RNR  |  HOST-REJ ]  + 
PACKET-RECE IVE-NUMBER 
CALLED  HOST  PROTOCOL  LAYER 


WINDOWED-CALLING-HOST-TO-CALLED-HOST-DATA- 

PACKET 

NONE 

WINDOWED-CALLING-HOST-TO-CALLED-HOST-DA TA- 
PACKET  =  [CALLING-HOST-TO-CALLED-HOST-DATA 
PACKET  +  PACKET-SEND-NUMBER  |  HOST-RR  ! 
HOST-RNR  I  HOST-REJ  ]  +  PACKET-RECF, IVE- 
NUMBER 

CALLING  HOST  PROTOCOL  LAYER 


199 


FILE  DEFINITIONS 


FILE  OR  DATABASE  NAME: 
ALIASES: 

COMPOSITION: 


ORGANIZATION: 
NOTES : 


CALLED-HOST-P ( R) 

NONE 

CALLED-HOST-P (R)  =  ARRAY  OF 
[0  !  1  |  2  |  3  I  4  |  5  |  6  |  7] 

WITH  1  VALUE  FOR  EACH  LOGICAL  CHANNEL 
ARRAY 

CALLED  HOST  PROTOCOL  LAYER 


FILE  OR  DATABASE  NAME: 
ALIASES: 

COMPOSITION: 


ORGANIZATION: 

NOTES: 


CALLED-HOST-P (S) 

NONE 

CALLED-HOST-P (S)  =  ARRAY  OF 
[0  |  1  I  2  I  3  |  4  |  5  I  6  I  7] 

WITH  1  VALUE  FOR  EACH  LOGICAL  CHANNEL 
ARRAY 

CALLED  HOST  PROTOCOL  LAYER 


FILE  OR  DATABASE  NAME: 
ALIASES: 

COMPOSITION: 


ORGANIZATION: 

NOTES: 


CALLED-NODE-P ( R) 

NONE 

CALLED-NODE-P (R)  =  ARRAY  OF 
[0  I  1  |  2  I  3  |  4  |  5  I  6  |  7] 

WITH  1  VALUE  FOR  EACH  LOGICAL  CHANNEL 
ARRAY 

CALLED  NODE  PROTOCOL  LAYER 


FILE  OR  DATABASE  NAME: 
ALIASES: 

COMPOSITION: 


ORGANIZATION: 

NOTES: 


CALLED-NODE-P (S) 

NONE 

CALLED-NODE-P (S)  =  ARRAY  OF 
[0  I  1  I  2  I  3  I  4  |  5  I  6  I  7] 

WITH  1  VALUE  FOR  EACH  LOGICAL  CHANNEL 
ARRAY 

CALLED  NODE  PROTOCOL  LAYER 


FILE  OR  DATABASE  NAME: 
ALIASES: 

COMPOSITION: 


ORGANIZATION: 

NOTES: 


CALLING-HOST-P (R) 

NONE 

CALLING-HOST-P (R)  =  ARRAY  OF 
[0  I  1  I  2  |  3  I  4  t  5  |  6  I  7] 

WITH  1  VALUE  FOR  EACH  LOGICAL  CHANNEL 
ARRAY 

CALLING  HOST  PROTOCOL  LAYER 
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FILE  OR  DATABASE  NAME: 
ALIASES: 

COMPOSITION: 


ORGANIZATION: 
NOTES : 


CALLING-HOST-P ( S) 

NONE 

CALLING-HOST-P (S)  =  ARRAY  OF 
[0  |  1  |  2  |  3  I  4  |  5  |  6  I  7] 

WITH  1  VALUE  FOR  EACH  LOGICAL  CHANNEL 
ARRAY 

CALLING  HOST  PROTOCOL  LAYER 


FILE  OR  DATABASE  NAME 
ALIASES: 

COMPOSITION: 


ORGANIZATION: 

NOTES: 


CALLING-NODE-P ( R) 

NONE 

CALLING-NODE-P (R)  =  ARRAY  OF 
[0  |  I  |  2  |  3  |  4  |  5  |  6  I  7] 

WITH  1  VALUE  FOR  EACH  LOGICAL  CHANNEL 
ARRAY 

CALLING  NODE  PROTOCOL  LAYER 


] 


FILE  OR  DATABASE  NAME 
ALIASES: 

COMPOSITION: 


ORGANIZATION: 

NOTES: 


CALLING-NODE-P (S) 

NONE 

CALLING-NODE-P (S)  =  ARRAY  OF 
[0  |  1  |  2  I  3  I  4  |  5  I  6  I  7] 

WITH  1  VALUE  FOR  EACH  LOGICAL  CHANNEL 
ARRAY 

CALLING  NODE  PROTOCOL  LAYER 


I 
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PROCESS  SPECIFICATIONS 


PROCESS  NAME:  DIVIDE  DATA  INTO  PACKETS 

PROCESS  NUMBER:  1.1 

PROCESS  DESCRIPTION: 

For  each  128  bytes 
Make  DATA-PACKET 

If  more  bytes  remain  then  use  MORE-DATA-BIT 
Else  use  LAST-PACKET-BIT 


PROCESS  NAME:  PLACE  CHANNNEL  IN  DATA  TRANSFER  STATE 

PROCESS  NUMBER:  1.2 

PROCESS  DESCRIPTION: 

Execute  NODE-CALL-SETUP-PACKET  by  making  state  transition 


specified  by 

the  table 

below : 

Present  State 

Next  State 

Call-Cnc 

Clr-I 

Reset-I 

Restart-I 

Rdy 

Error 

Error 

Error 

P-Restart 

Dat-Tr 

a)  P-Reset 

Error 

P-Clr 

FC-Rdy 

P-Restart 

b)  FC-Rdy 

Error 

P-Clr 

P-Reset 

P-Restart 

P-Clr 

P-Clr 

Rdy 

P-Clr 

P-Restart 

P-Restart 

P-Restart 

P-Restart 

P-Restart 

Rdy 

Call-Set 

FC-Rdy 

Rdy 

Error 

P-Restart 

Present  State 

Next  State 

Reset-C 

Restart-C 

Clr-C 

Rdy 

Error 

Error 

Error 

Dat-Tr 

a)  P-Reset 

FC-Rdy 

Error 

Error 

b)  FC-Rdy 

Error 

Error 

Error 

P-Clr 

Error 

Error 

Rdy 

P-Restart 

Error 

Rdy 

Error 

Call-Set 

Error 

Error 

Error 

Where 

Call-Cnc  =  Call-Connected-Packet 
Clr-I  =  Clear-Indication-Packet 
Reset-I  =  Reset-Indication-Packet 
Restart-I  =  Restart-Indication-Packet 
Reset-C  =  Reset-Confirmation-Packet 
Clr-C  =  Clear-Conf irmation-Packet 
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Rdy  =  Ready  State 
Dat-Tr  =  Data  Transfer  State 
P-Reset  =  Pending  Reset  State 
FC-Rdy  =  Flow  Control  Ready  State 
P-Clr  =  Pending  Clear  State 
P-Restart  =  Pending  Restart  State 
Call-Set  =  Call  Setup  State 

Case  state  of 

Ready:  If  CALLING-HOST-TO-CALLED-HOST-DATA- PACKET 

available  then 

Set  up  call  by  sending  CALL-REQUEST-PACKET  and 
entering  Call  Setup  State 

Pending 

Reset:  If  RESET-REQUEST-PACKET  has  not  been  sent  or  if 
max-time-f or-response  has  elapsed  then 
send  RESET-REQUEST-PACKET  and  restart  timer 

Flow 

Control 

Ready:  Queue  CALLING-HOST-TO-CALLED-HOST-DATA-PACKET  for 
channel 

Pending 

Clear:  If  CLEAR-REQUEST-PACKET  has  not  been  sent  or  if 
max-time-f or-response  has  elapsed  then 
send  CLEAR-REQUEST-PACKET  and  restart  timer 

Pending 

Restart:  If  RESTART-REQUEST-PACKET  has  not  been  sent  or  if 
max-time-for-response  has  elapsed  then 
send  RESTART-REQUEST-PACKET  and  restart  timer 

Call 

Setup:  If  max-time-for-response  has  elapsed  then  send 
CALL-REQUEST-PACKET  and  restart  timer 

Error:  Send  RESTART-REQUEST-PACKET  and  enter  Pending 

Restart  State 


PROCESS  NAME:  WINDOW  CALLING-HOST-TO-CALLED-HOST- 

DATA-PACKET 

PROCESS  NUMBER:  1.3 

PROCESS  DESCRIPTION: 

Case  of  CALLING-NODE-SUPERVISORY-PACKET 

NODE-RR-PACKET:  Calling  Node  State  =  Ready 

P ( R)  =  P ( R)  Of  NODE-RR-PACKET 
NODE-RNR-PACKET:  Calling  Node  State  =  Not  Ready 

P ( R)  =  P ( R)  of  NODE-RNR-PACKET 
NODE-REJ-PACKET:  Calling  Node  State  =  Ready 

P ( R)  =  P { R)  of  NODE-REJ-PACKET 
While  P (S) <P (R)  then  Send  a  CALLING-HOST-TO-CALLED-HOST- 
DATA-PACKET  from  the  queue  and  increment  P(S)  modulo  8 
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PROCESS  NAME:  SEND  PACKET  TO  CALLING  NODE 

PROCESS  NUMBER:  1.4 

PROCESS  DESCRIPTION: 

Place  Packet  in  Shared  Memory  Priority  Queue  for  CALLING  NODE 
Priority  1:  CALLING-HOST-INTERRUPT-CONFIRMATION-PACKET 
Priority  2:  HOST-CALL-SETUP-PACKET 

Priority  3:  WINDOWED-CALL ING-HOST-TO-CALLED-HOST-DATA- 
PACKET 

(Priority  1  is  highest) 


PROCESS  NAME:  DETERMINE  CALLING-NODE-TO-CALLING- 

HOST-PACKET  TYPE 
PROCESS  NUMBER:  1.5 

PROCESS  DESCRIPTION: 

If  Octet  3  =  (00001011)  or  (00001111)  or  (00010011)  or 
(00010111)  then  CALLING-NODE-TO-CALLING-HOST-PACKET  is  a 
NODE-CALL-SETUP-PACKET 

Else  if  Octet  3  =  (XXX00001)  or  (XXX00101)  or  (XXX01001)  or 
(00011011)  or  (00011111)  then  CALL1NG-NODE-TO-CALLING-HOST- 
PACKET  is  a  CALLING-NODE-SUPERVISORY-PACKET 
Else  if  Octet  3  =  (XXXXXXX0)  then  CALL ING-NODE-TO-CALL ING¬ 
HOST-PACKET  is  a  CALLED-HOST-TO-CALLING-HOST-DATA- PACKET 
Else  if  Octet  3  =  (00100011)  then  CALL ING-NODE- TO-CALL ING¬ 
HOST-PACKET  is  a  CAT.LED-HOST-TO-CALLING-HOST-NODE- 
INTERRUPT-PACKET 


PROCESS  NAME:  DETERMINE  DATA  PACKET  CATEGORY  AND 

EXTRACT  FLOW  CONTROL 

PROCESS  NUMBER:  1.6 

PROCESS  DESCRIPTION: 

P (R)  =  Bits  8,7,6  of  Octet  3  of  CALLED-HOST-TO-CALLING-HOST- 
DATA-PACKET 

P(S)  =  Bits  4,3,2  Of  Octet  3  of  CALLED-HOST-TO-CALLING-HOST- 
DATA-PACKET 

If  Bit  5  Of  Octet  3  Of  CALLED-HOST-TO-CALLING-HOST-DATA- 
PACKET  =  0  then  CALLED-HOST-TO-CALLING-HOST-DATA- PACKET  is 
a  CATEGORY-1 -PACKET 

Else  CALLED-HOST-TO-CALLING-HOST-DATA-PACKET  is  a  CATEGORY - 
2-PACKET 


PROCESS  NAME:  BUFFER  PACKET  SEQUENCE 

PROCESS  NUMBER:  1.7 

PROCESS  DESCRIPTION: 

Extract  CALLED-HOST-TO-CALLING-HOST  Data  Field  and 
append  to  end  of  Data  Fields  already  buffered 
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PROCESS  NAME:  ASSEMBLE  PACKET  SEQUENCE 

PROCESS  NUMBER:  1.8 

PROCESS  DESCRIPTION: 

When  a  CATEGORY-1 -PACKET  is  received 
Append  Data  Field  to  end  of  BUFFERED-SEQUENCE 


PROCESS  NAME:  CONFIRM  RECEIPT  OF  INTERRUPT  PACKET 

PROCESS  NUMBER:  1.9 

PROCESS  DESCRIPTION: 

Send  HOST- INTERRUPT-CONFIRMATION-PACKET 

Extract  INTERRUPT-USER-DATA  from  CALLED-HOST-TO-CALLING- 
HOST-NODE-INTERRU PT- PACKET  which  is  contained  in  Octet  4 


PROCESS  NAME:  SEND  DATA  TO  CALLING  HOST 

PROCESS  NUMBER:  1.10 

PROCESS  DESCRIPTION: 

Place  CALLED-HOST-TO-CALLING-HOST-INTERRUPT-DATA  and 
CALLED-HOST-TO-CALLING-HOST-COMPLETE-PACKET-SEQUENCE  in 
priority  queue  for  transmission  to  CALLING  HOST  by 
VIRTUAL  TERMINAL  PROTOCOL 
Priority  1  (highest)  INTERRUPT-DATA 
Priority  2  COMPLETE-PACKET-SEQUENCE 


PROCESS  NAME:  DETERMINE  CALLING-HOST-PACKET  TYPE 

PROCESS  NUMBER:  2.1.1 

PROCESS  DESCRIPTION: 


Case  Octet  3  of 

(00001011) :  RECEIVED-CALL-REQUEST-PACKET 

(XXXXXXX0) :  RECEIVED-WINDOWED-CALLING-HOST-TO-CALLED-HOST- 


(00100011)  : 
(00010011)  : 
(00011011)  ; 
(11111011)  : 
(00010111)  or 
(00100111)  or 
(00011111)  or 
(11111111) : 
(XXX00001)  or 
(XXX00101)  or 
(XXX01001) : 


DATA-PACKET 

RECEIVED-CALLING-HOST- INTERRUPT-PACKET 
RECEIVED-CALL ING-HOST-CLEAR-REQUEST 
RECEIVED-CALLING-HOST-RESET-REQUEST 
RECEIVED-CALLING-HOST-RESTART-REQUEST 


CALLING-HOST-CONFIRMATION-PACKET 


CALLING-HOST-SUPERVISORY-PACKET 


otherwise : 


INVALID-PACKET-TYPE 
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PROCESS  NAME:  NOTIFY  CALLED  NODE  OF  INCOMING  CALL 

PROCESS  NUMBER:  2.1.2 

PROCESS  DESCRIPTION: 

Set  State  of  CALLING  NODE  to  Call  Setup  State 
Send  CALL-REQUEST-PACKET  as  INCOMING-CALL-PACKET  to 
CALLED  NODE 


PROCESS  NAME:  UPDATE  CALLING  NODE  WINDOWING  VARIABLES 

PROCESS  NUMBER:  2.1.3 

PROCESS  DESCRIPTION: 

P ( R)  =  Bits  8,7,6  of  Octet  3  of  RECEIVED-WINDOWED-CALLING- 
HOST-TO-CALLED-HOST-DATA- PACKET 
P(S)  =  Bits  4,3,2  of  Octet  3  of  RECE IVED-WINDOWED-CALLING- 
HOST-TO-CALLED-HOST-DATA-PACKET 


PROCESS  NAME:  CONFIRM  RECEIPT  OF  CALLING-HOST- 

INTERRUPT 

PROCESS  NUMBER:  2.1.4 

PROCESS  DESCRIPTION: 

Send  CALLING-NODE-INTERRUPT-CONFIRMATION-PACKET  to  CALLING- 
HOST  upon  receipt  of  a  RECE I VED -CAL LING - HOST- INTERRUPT - 
PACKET 


PROCESS  NAME:  CONFIRM  CALLING  HOST  CLEAR  REQUEST 

PROCESS  NUMBER:  2.1.5 

PROCESS  DESCRIPTION: 

Send  any  remaining  CALLING-HOST-TO-CALLED-HOST-DATA- PACKETS 
to  CALLED-NODE 

Clear  virtual  call  and  set  CALLING  NODE  state  to  Ready  State 
Send  CALLING-NODE-CLEAR-CONFIRMATION-PACKET  to  CALLING-HOST 


PROCESS  NAME:  CONFIRM  CALLING  HOST  RESET  REQUEST 

PROCESS  NUMBER:  2.1.6 

PROCESS  DESCRIPTION: 

Reset  P(R)  and  P(S)  to  zero  for  the  channel  specified  in  the 
RESET-REQUEST-PACKET 

Set  CALLING-NODE  state  to  Flow  Control  Ready  state 

Send  CALLING-NODE-RESET-CONFIRMATION-PACKET  to  CALLING-HOST 
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PROCESS  NAME:  CONFIRM  CALLING  HOST  RESTART  REQUEST 

PROCESS  NUMBER:  2.1.7 

PROCESS  DESCRIPTION: 

Reset  all  P(S)  and  P(R)  for  the  CALLING-NODE 

Set  the  state  of  virtual  circuits  to  Flow  Control  Ready 

Set  the  state  of  virtual  channels  to  Ready 

Send  CALLING-NODE-RESTART-CONFIRMATION-PACKET  to  CALLING-HOST 


PROCESS  NAME: 

PROCESS  NUMBER: 
PROCESS  DESCRIPTION: 
Place  PACKET  in  queue 
Level  2  Protocol  and 


SEND  PACKET  ONTO  NETWORK 

2.2 


for  transmission  by  the 
the  Routing  Algorithm 


PROCESS  NAME:  DETERMINE  CALLED-NODE-PACKET  TYPE 

PROCESS  NUMBER:  2.3.1 

PROCESS  DESCRIPTION: 


Case  Octet  3  of 


(00100011) 
(00001111) 
(XXXXXXX0) 
otherwj  se : 


RECEIVED-CALLED-NODE- INTERRUPT- PACKET 
RECEIVED-CALL-ACCEPTED-PACKET 

RECE IVED-CALLED -HOST- TO-CALLING -HOST-DATA- PACKET 
INVALID-PACKET  TYPE 


PROCESS  NAME:  INTERRUPT  CALLING  NODE  TO  CALLING  HOST 

DATA  FLOW 

PROCESS  NUMBER:  2.3.2 

PROCESS  DESCRIPTION: 

Transfer  CALLED-HOST- INTERRUPT-DATA  from  RECE IVED-CALLED- 
NODE-PACKET  to  CALLING-NODE- INTERRUPT-PACKET 


PROCESS  NAME:  NOTIFY  CALLING  HOST  OF  CALL  CONNECTION 

PROCESS  NUMBER:  2.3.3 

PROCESS  DESCRIPTION: 

If  in  Call  Setup  state  and  CALL-ACCEPTED-PACKET  received 
from  CALLED  NODE  then  send  CALL-CONNECTED-PACKET  to  CALLING 
NODE 

If  not  in  Call  Setup  state  and  CALL-ACCEPTED-PACKET  received 
then  discard  packet 

If  in  Call  Setup  state  and  no  CALL-ACCEPTED-PACKET  is 
received  prior  to  expiration  of  max-time-f or-cal 1-setup- 
timer  then  send  CALLING-NODE-CLEAR- INDICATION -PACKET  to 
CALLING  HOST 
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PROCESS  NAME:  WINDOW  CALLED-HOST-TO-CALLING-IJCST- 

DATA-PACKETS 

PROCESS  NUMBER:  2.3.4 

PROCESS  DESCRIPTION: 

Case  CALLING -HOST- SUPERVISORY -PACKET  of 

HOST-RR:  Set  CALLING  NODE  state  to  Ready 

HOST-RNR:  Set  CALLING  NODE  state  to  Not  Ready 

HOST-REJ:  Set  CALLING  NODE  state  to  Ready 

Set  P ( R)  =  Bits  8,7,6  of  Octet  3  of  CALLING-HCST-SUPERVISORY- 

PACKET 

While  there  are  R EC E I VED -CALLED -HOST-TO-CALLING- HOST-DATA - 
PACKETS  available  for  transmission  to  the  CALLING  HOST 
and  while  P(S)<P(R)  send  CALLING-NODE-WINDOWED-CALLED-HOST- 
TO-CALLING-HOST-DATA- PACKETS  to  CALLING  HOST 

If  no  DATA-PACKETS  available  for  transmission  for  max-time- 
between-updates  then  send  CALLING-NODE-SUPERVISORY-PACKET 
to  CALLING  HOST 


PROCESS  NAME:  SEND  PACKET  TO  CALLING  HOST 

PROCESS  NUMBER:  2.4 

PROCESS  DESCRIPTION: 

Place  Packet  in  Shared  Memory  Priority  Queue  for  CALLING-HOST 
Priority  1:  RESTART- INDICATION-PACKET 

Priority  2:  CALLED-HOST-TO-CALLING-HOST-NODF- INTERRUPT- 
PACKET 

Priority  3:  CALLING-NODE-CONFIRMATION-PACKETS 
Priority  4:  CALL ED-HOST- TO -CALLING -HOST-DATA- PACKETS 
Priority  5:  CALLING-NODE-SUPERVISORY-PACKETS 
(Priority  1  is  the  highest) 


PROCESS  NAME:  RECOVER  FROM  PROCEDURE  ERROR 

PROCESS  NUMBER:  2.5 

PROCESS  DESCRIPTION: 

Upon  detection  of  a  LOCAL-PROCEDURE-ERROR  send  an 
ERROR-RECOVERY-PACKET  to  the  CALLING  HOST 


PROCESS  NAME:  DETERMINE  CALLED-HOST-PACKET  TYPE 

PROCESS  NUMBER:  4.1.1 


PROCESS  DESCRIPTION: 
Case  Octet  3  of 


(00001111) : 
(XXXXXXXO) : 

(00100011) : 
(00010011) : 
(00011011)  : 
(11111011)  : 
(00010111)  or 
(00100111)  or 
(00011111)  or 
(11111111) : 
(XXX00001)  or 
(XXX00101)  or 
(XXX01001) : 
otherwise : 


RECEIVED-CALL-ACCEPTED-PACKET 

RECE IVED-WINDOWED-CALLED-HOST-TO-CALLING-HCST- 
DATA-PACKET 

RECE IVED-CALLED-HOST- INTERRUPT-PACKET 
RECEIVED-CALLED-HOST-CLEAR-REQUEST 
RECEIVED-CALLED-HOST-RESET-REQUEST 
RECEIVED-CALLED-HOST-RESTART-REQUEET 


CALLED- HOST-CONFIRMATION -PACKET 


CALLED-HOST-SUPERVISORY-PACKET 

INVALID-PACKET-TYPE 


PROCESS  NAME:  RELAY  CALL  ACCEPTANCE  TO  CALLING  NODE 

PROCESS  NUMBER:  4.1.2 

PROCESS  DESCRIPTION: 

Set  state  of  CALLED  NODE  to  Flow  Control  Ready  state 
Send  RELAYED-CALL-ACCEPTANCE-PACKET  to  CALLING  NODE 


PROCESS  NAME:  UPDATE  CALLED  NODE  WINDOWING  VARIABLES 

PROCESS  NUMBER:  4.1.3 

PROCESS  DESCRIPTION: 

P (R)  =  Bits  8,7,6  of  Octet  3  of  RECEIVED-WINDOWED-CALLED- 
HOST-TO-CALLING-HOST-DATA-PACKET 
P ( S)  =  Bits  4,3,2  of  Octet  3  of  RECEIVED-WINDOWED-CALLED- 
HOST-TO-CALLING-HOST-DATA-PACKET 


PROCESS  NAME:  CONFIRM  RECEIPT  OF  CALLED-HOST- 

INTERRUPT 

PROCESS  NUMBER:  4.1.4 

PROCESS  DESCRIPTION: 

Send  CALLED-NODE- INTERRUPT-CONFIRMATION- PACKET  to  CALLED- 
HOST  upon  receipt  of  a  RECEIVED-CALLED-HOST- INTERRUPT- 
PACKET 
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PROCESS  NAME:  CONFIRM  CALLED  HOST  CLEAR  REQUEST 

PROCESS  NUMBER:  4.1.5 

PROCESS  DESCRIPTION: 

Send  any  remaining  CALLED-HOST-TO-CALLING-HOST-DATA-PACKETs 
to  CALLING  NODE 

Clear  virtual  call  and  set  CALLED  NODE  state  to  Ready  state 
Send  CALLED-NODE-CLEAR-CONF I RMAT ION-PACKET  to  CALLING-HOST 


PROCESS  NAME:  CONFIRM  CALLING  HOST  RESET  REQUEST 

PROCESS  NUMBER:  4.1.6 

PROCESS  DESCRIPTION: 

Reset  P ( R)  and  P(S)  for  the  CALLED  NODE 

Set  CALLED  NODE  state  to  Flow  Control  Ready  state 

Send  CALLED-NODE-RESET-CONFIRMATION-PACKET  to  CALLED  HOST 


PROCESS  NAME:  CONFIRM  CALLED  HOST  RESTART  REQUEST 

PROCESS  NUMBER:  4.1.7 

PROCESS  DESCRIPTION: 

Reset  all  P(R)  and  P(S)  for  the  CALLED  NODE 

Set  the  state  of  the  virtual  circuits  to  Flow  Control  Ready 

Set  the  state  of  the  virtual  channels  to  Ready 

Send  CALLED-NODE-RESTART-CONFIRMATION-PACKET  to  CALLED  HOST 


PROCESS  NAME: 

PROCESS  NUMBER: 
PROCESS  DESCRIPTION: 


SEND  PACKET  ONTO  NETWORK 
4.2 

SEE  PROCESS  2.2 


PROCESS  NAME:  DETERMINE  CALLING  NODE  PACKET  TYPE 

PROCESS  NUMBER:  4.3.1 

PROCESS  DESCRIPTION: 

Case  Octet  3  of 


(00100011) 
(00001011) 
(XXXXXXX0) 
otherwise : 


RECEIVED-CALLING-NODE-INTERRUPT-PACKET 

RECEIVED-INCOMING-CALL-PACKET 

RECEIVED-CALL ING-HCST -TO-CALLED- HOST- DATA- PACKET 
INVALID-PACKET  TYPE 


PROCESS  NAME:  INTERRUPT  CALLED  NODE  TO  CALLED  HOST 

DATA  FLOW 

PROCESS  NUMBER:  4.3.2 

PROCESS  DESCRIPTION: 

Transfer  CALLING-HOST-INTERRUPT-DATA  from  RECEIVED-CALLING- 
NODE-INTERRUPT-PACKET  to  CALLED-NODE-INTERRUPT-PACKET 
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NOTIFY  CALLED  HOST  OF  INCOMING  CALL 
4.3.3 


PROCESS  NAME: 

PROCESS  NUMBER: 

PROCESS  DESCRIPTION: 

If  in  Ready  state  then  relay  RECEIVED-INCOMING-CALL-PACKET 
to  CALLING  HOST  and  set  CALLED  NODE  state  to  Call  Setup 
state 

Else  discard  packet 


PROCESS  NAME:  WINDOW  CALLING- HOST- TO-CALLED- HOST- 

DATA-  PACKETS 

PROCESS  NUMBER:  4.3.4 

PROCESS  DESCRIPTION: 

Case  CALLED-HOST-SUPERVISORY-PACKET  of 

HOST-RR, HOST-REJ :  Set  CALLED  NODE  state  to  Ready 

HOST-RNR:  Set  CALLED  NODE  state  to  Not  Ready 

Set  P (R)  =  Bits  8,7,6  of  Octet  3  of  CALLED-HOST-SUPERVISORY- 
PACKET 

While  there  are  RECEIVED -CALL ING-HOST-TO-CALLED-HOST-DA TA- 
PACKETS  available  for  transmission  to  the  CALLED  HOST  and 
while  P(S)  <  P ( R)  send  CALLED-NODE-WINDOWED-CALLING-HOST- 
TO-CALLED-HOST-DATA-PACKETs  to  CALLED  HOST 

If  no  DATA-PACKETS  available  for  transmission  for  max-time- 
between-updates  then  send  CALLED-NODE-SUPERVISORY-PACKET 
to  CALLED  HOST 


PROCESS  NAME:  SEND  PACKET  TO  CALLED  HOST 

PROCESS  NUMBER;  4.4 

PROCESS  DESCRIPTION: 


Place  Packet 
Priority 
Priority 

Priority 

Priority 

Priority 


in  Shared  Memory  Priority  Queue  for  CALLED-HOST 
1:  RESTART- INDICATION-PACKET 

2 :  CALLING-HO ST-TO-CALLED -HOST-NODE- INTERRUPT- 

PACKET 

3 :  CALLED-NODE-CONFIRMATION-PACKETS 

4 :  CALLING-HOST-TO-CALLED-HOST-DATA- PACKETS 

5 :  CALLED-NODE-SUPERVISORY-PACKETS 


(Priority  1  is  the  highest) 


PROCESS  NAME:  RECOVER  FROM  PROCEDURE  ERROR 

PROCESS  NUMBER:  4.5 

PROCESS  DESCRIPTION: 

Upon  detection  of  a  PROCEDURE-ERROR  send  an 
ERROR-RECOVERY-PACKET  to  the  CALLED-HOST 
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PROCESS  NAME:  DIVIDE  DATA  INTO  PACKETS 

PROCESS  NUMBER:  5.1 

PROCESS  DESCRIPTION:  SEE  PROCESS  1.1 


PROCESS  NAME:  KEEP  CHANNEL  IN  DATA  TRANSFER  STATE 

PROCESS  NUMBER:  5.2 

PROCESS  DESCRIPTION: 

Execute  NODE-CALL-MAINTENANCE-PACKET  by  making  the  state 
transition  specified  by  the  table  below: 


Present  State 

Next 

State 

Inc-Call 

Clr-I 

Reset-I 

Restart-I 

Rdy 

FC-Rdy 

Error 

Error 

P-Restart 

Dat-Tr 

a) P-Reset 

P-Reset 

P-Clr 

FC-Rdy 

P-Restart 

b) FC-Rdy 

FC-Rdy 

P-Clr 

P-Reset 

P-Restart 

P-Clr 

P-Clr 

Rdy 

P-Clr 

P-Restart 

P-Restart 

P-Restart 

P-Restart 

P-Restart 

Rdy 

Present  State 

Next 

State 

Reset-C 

Restart- 

C  Clr-C 

Rdy 

Error 

Error 

Error 

Dat-Tr 

a) P-Reset 

FC-Rdy 

Error 

Error 

b) FC-Rdy 

Error 

Error 

Error 

P-Clr 

Error 

Error 

Rdy 

P-Restart 

Error 

Rdy 

Error 

Where 

Inc-Call  =  Incoming-Call-Packet 
Clr-I  =  Clear-Indication-Packet 
Reset-I  =  Reset-Indication-Packet 
Restart-I  =  Restart-Indication-Packet 
Reset-C  =  Reset-Confirmation-Packet 
Clr-C  =  Clear-Conf irmation-Packet 
Rdy  =  Ready  State 
Dat-Tr  =  Data  Transfer  State 
P-Reset  =  Pending  Reset  State 
FC-Rdy  =  Flow  Control  Ready  State 
P-Clr  =  Pending  Clear  State 
P-Restart  =  Pending  Restart  State 


Case  state  of 


Ready:  If  INCOMING-CALL-PACKET  received  from  CALLED 

NODE  then  send  CALL-ACCEPTED-PACKET  back  to 
CALLED  NODE 

Pending 

Reset:  If  RESET-REQUFST-PACKET  has  not  been  sent  or  if 
max-time-f or-response  has  elapsed  then 
send  RESET-REQUEST-PACKET  and  restart  timer 

Flow 

Control 

Ready:  Queue  CALLED-HOST- TO-CALLING- HOST-DA TA-PACKET  for 
channel 

Pending 

Clear:  If  CLEAR-REQUEST-PACKET  has  not  been  sent  or  if 
max-time-f or-response  has  elapsed  then 
send  CLEAR-REQUEST-PACKET  and  restart  timer 

Pending 

Restart:  If  RESTART-REQUEST-PACKET  has  not  been  sent  or  if 
max-time-f or-response  has  elapsed  then 
send  RESTART-REQUEST-PACKET  and  restart  timer 
Error:  Send  RESTART-REQUEST-PACKET  and  enter  Pending 

Restart  State 


PROCESS  NAME:  WINDOW  CALLED-HOST-TO-CALLING-HCST- 

DATA-PACKET 

PROCESS  NUMBER:  5.3 

PROCESS  DESCRIPTION: 

Case  Of  CALLED-NODF-SUPERVISORY-PACKET 

NODE-RR-PACKET:  Called  Node  State  =  Ready 

P ( R)  =  P { R)  of  NODE-RR-PACKET 
NODE-RNR- PACKET:  Called  Node  State  =  Not  Ready 

P ( R)  =  P ( R)  of  NODE  -RNR- PACKET 
NODE-REJ-PACKET;  Called  Node  State  =  Ready 

P ( R)  =  P ( R )  of  NODE-REJ-PACKET 
While  P (S) <P (R)  then  Send  a  CAL LED- HO ST- TO-CALLING -HOST- 
DA  TA-PACKET  from  the  queue  and  increment  P(S)  modulo  8 


PROCESS  NAME:  SEND  PACKET  TO  CALLED  NODE 

PROCESS  NUMBER:  5.4 

PROCESS  DESCRIPTION: 

Place  Packet  in  Shared  Memory  Priority  Queue  for  CALLED  NODE 
Priority  1:  CALLED-HOST- INTERRU PT-CONFIRMATION-PACKET 
Priority  2:  HOST-CALL-MAINTENANCE-PACKET 
Priority  3:  WIN DOW ED-CALLED -HOST- TO- CAL LING -HOST- DA TA- 
PACKET 

(Priority  1  is  highest) 
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PROCESS  NAME:  DETERMINE  CALLED-NODE-TO-CALLED-HOST 

PACKET  TYPE 

PROCESS  NUMBER:  5.5 

PROCESS  DESCRIPTION: 

If  Octet  3  =  (00001011)  or  (00010011)  or  (00010111) 
or  (00011011)  or  (00011111)  or  (11111011)  or  (11111111) 
then  CALLED-NODE-TO-CALLED-HOST-PACKET  is  a 
NODE-CALL-MAINTENANCE-PACKET 

Else  if  Octet  3  =  (XXX00001)  or  (XXX00101)  or  (XXX01001)  or 
then  CALLED-NODE-TO-CALLED-HOST-PACKET  is  a 
CALLED-NODE-SUPERVISORY-PACKET 
Else  if  Octet  3  =  (XXXXXXX0)  then  CALLED-NODE-TO-CALLED- 
HOST-  PACKET  is  a  CALLING-HOST-TO-CALLED-HOST-DATA-PACKET 
Else  if  Octet  3  =  (00100011)  then  CALLED-NODE-TO-CALLED- 
HOST-PACKET  is  a  CALLING-HOST-TO-CALLED-HOST-NODE- 
INTERRUPT-PACKET 


PROCESS  NAME:  DETERMINE  DATA  PACKET  CATEGORY  AND 

EXTRACT  FLOW  CONTROL 

PROCESS  NUMBER:  5.6 

PROCESS  DEFINITION: 

P(R)  =  Bits  8,7,6  of  Octet  3  of  CALLING-HOST-TO-CALLED-HOST 
DATA-PACKET 

P(S)  =  Bits  4,3,2  of  Octet  3  of  CALLING-HOST-TO-CALLED-HOST 
DATA-PACKET 

If  Bit  5  of  Octet  3  of  CALLING-HOST-TO-CALLED-HOST-DATA- 
PACKET  =  0  then  CALLING-HOST-TO-CALLED-HOST-DATA- PACKET  is 
a  CATEGORY-1 -PACKET 

Else  CALLING-HOST- TO-CALLED -HOST-DATA- PACKET  is  a  CATEGORY - 
2-PACKET 


PROCESS  NAME:  BUFFER  PACKET  SEQUENCE 

PROCESS  NUMBER:  5.7 

PROCESS  DESCRIPTION: 

Extract  CALLING-HOST-TO-CALLED-HOST  Data  Field  and 
append  to  end  of  Data  Fields  already  buffered 


PROCESS  NAME:  ASSEMBLE  PACKET  SEQUENCE 

PROCESS  NUMBER:  5.8 

PROCESS  DESCRIPTION:  SEE  PROCESS  1.8 
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PROCESS  NAME:  CONFIRM  RECEIPT  OF  INTERRUPT  PACKET 

PROCESS  NUMBER:  5.9 

PROCESS  DESCRIPTION: 

Send  HOST- INTERRUPT-CONFIRMATION-PACKET 

Extract  INTERRUPT-USER-DATA  from  CALLING-HOST-TO-CALLED- 
HOST-NODE- INTERRUPT- PACKET  which  is  contained  in  Octet  4 


PROCESS  NAME:  SEND  DATA  TO  CALLED  HOST 

PROCESS  NUMBER:  5.10 

PROCESS  DESCRIPTION: 

Place  CALLING-HOST-TO-CALLED-HOST- INTERRUPT-DATA  and 
CALLING-HOST-TO-CALLED-HOST-COMPLETE-PACKET-SEQUENCE  in 
priority  queue  for  transmission  to  CALLED  HOST  by 
VIRTUAL  TERMINAL  PROTOCOL 
Priority  1  (highest)  INTERRUPT-DATA 
Priority  2  COMPLETE-PACKET-SEQUENCE 
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DATA  DICTIONARY 


FOR  NETWORK  PROTOCOL 


DATA  ELEMENT  NAME: 
ALIASES: 

VALUES  AND  MEANINGS: 


NOTES: 


IN-TRANSIT-PACKET 

NONE 

ANY  LEVEL  3  PACKET  THAT  HAS  BEEN 
DETERMINED  TO  NOT  BE  AT  ITS  DESTINATION 
NODE 

OVERVIEW  LAYER 


DATA  ELEMENT  NAME: 
ALIASES: 

VALUES  AND  MEANINGS: 


NOTES: 


SOURCE -NODE -LEVEL-2- PACKET 
NONE 

ANY  LEVEL  3  PACKET  THAT  HAS  BEEN 
PASSED  FROM  THE  SOURCE  HOST  TO  THE 
NODE  SERVING  THAT  HOST  AS  AN  ENTRY 
POINT  TO  THE  NETWORK 
CONTEXT  LAYER 


DATA  ELEMENT  NAME: 
ALIASES: 

VALUES  AND  MEANINGS: 
NOTES: 


TRANSMITTED-PACKET 

NONE 

ANY  LEVEL  3  PACKET  THAT  HAS  BEEN 
TRANSMITTED  FROM  ONE  NODE  TO  ANOTHER 
OVERVIEW  LAYER 


DATA  ELEMENT  NAME: 
ALIASES: 

VALUES  AND  MEANINGS: 


NOTES: 


TRAN SMITTED-SOURCE-NODE-LEVEL-3 -PACKET 
TRANSMITTED-SOURCE-NODE-PACKET 
ANY  LEVEL  3  PACKET  THAT  HAS  BEEN 
TRANSMITTED  ACROSS  THE  NETWORK  TO  THE 
NODE  THAT  SERVES  AS  THE  ENTRY  POINT 
FOR  THE  HOST  THAT  IS  THE  PACKET’S 
DESTINATION 
CONTEXT  LAYER 


DATA  ELEMENT  NAME: 
ALIASES: 

VALUES  AND  MEANINGS: 
NOTES: 


TRANSMITTED-SOUkCE-NODE-PACKET 
TRAN SMITTED-SOURCE-NODE-LEVEL-3 -PACKET 
SEE  ALIAS 
SEE  ALIAS 


FILE  DEFINITIONS 


FILE  OR  DATABASE  NAME:  ROUTING-LOOKUP-TABLE 
ALIASES:  NONE 

COMPOSITION:  ROUTING-LOOKUP-TABLE  = 

{DESTINATION-NODE  +  NEXT-CLOSER-NODE} 
ORGANIZATION:  ARRAY 

EACH  NODE  MUST  HAVE  ITS  OWN  LOOKUP 
TABLE  STORED  IN  IT 

NOTES:  OVERVIEW  LAYER 
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PROCESS  SPECIFICATIONS 


PROCESS  NAME:  DETERMINE  THE  NEXT  CLOSER  NODE 

PROCESS  NUMBER:  1 

PROCESS  DESCRIPTION: 

Access  the  ROUTING-LOOKUP-TABLE  using  the  LEVEL-3-PACKET' s 
DEST-HOST  field  to  find  the  NEXT-CLOSER-NODE 
If  the  NEXT-CLOSER-NODE  is  the  PRESENT-NODE  then  pass  the 
LEVEL-3 -PACKET  to  the  LEVEL-3 -NODE-PROTOCOL 
Else  output  the  LEVEL -3 -PACKET  as  an  IN-TRANSIT-PACKET  with 
the  NEXT-CLOSER-NODE  as  the  NEXT-PACKET-DESTINATION 


PROCESS  NAME:  TRANSMIT  PACKET  TO  ROUTED  NODE 

PROCESS  NUMBER:  2 

PROCESS  DESCRIPTION: 

Use  the  X.25  Level  2  Protocol  to  transmit  the  IN-TRANSIT- 
PA^KET  to  the  NEXT-PACKET-DESTINATION  as  a  TRANSMITTED- 
PACKET 


Ij 


DATA  DICTIONARY 


FOR 


DATA  ELEMENT  NAME: 
ALIASES: 

VALUES  AND  MEANINGS: 
NOTES: 


DATA  ELEMENT  NAME: 
ALIASES: 

VALUES  AND  MEANINGS: 


NOTES: 


DATA  ELEMENT  NAME: 
ALIASES: 

VALUES  AND  MEANINGS: 


NOTES: 


DATA  ELEMENT  NAME: 
ALIASES: 

VALUES  AND  MEANINGS: 
NOTES: 


DATA  ELEMENT  NAME: 
ALIASES: 

VALUES  AND  MEANINGS: 
NOTES: 


X . 2 5  LEVEL  2  PROTOCOL 


ABORTED-PACKET 

NONE 

ANY  PACKET  CONTAINING  A  SEQUENCE  OF 
SEVEN  CONSECUTIVF  l'S 
EXTRACT  VALID  PACKET  LAYER 


ADDRESS-FIELD 

NONE 

8  BIT  FIELD 

(10000000)  =  PRIMARY  TO  SECONDARY 

COMMAND  OR  SECONDARY  TO 
PRIMARY  RESPONSE 

(11000000)  =  PRIMARY  TO  SECONDARY 

RESPONSE  OR  SECONDARY  TO 
PRIMARY  COMMAND 

HDLC  PR I MARY, SECONDARY  PROTOCOL  LAYERS 


BUSY-INDICATION 

NONE 

TWO-BIT  CODE  WITH  VALUE  =10 
INDICATES  THAT  THE  SECONDARY  NODE  IS 
NOT  READY  TO  RECEIVE  LEVEL- 2 -PACKETS 
EXECUTE  S-FRAME  RESPONSE  LAYER, 

WINDOW  PRIMARY  INFORMATION  BLOCKS  LAYER 


BUSY-N(R) 

N(R) 

SEE  ALIAS 

EXECUTE  S-FRAME-RESPONSE  LAYER, 

WINDOW  PRIMARY  INFORMATION  BLOCKS  LAYER 


BUSY-PRIMARY-N ( R) 

PRIMARY-N ( R) 

SEE  ALIAS 

EXECUTE  S-FRAME  COMMAND  LAYER, 
WINDOW  SECONDARY  INFORMATION  BLOCKS 
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DATA  ELEMENT  NAME: 

ALIASES: 

COMPOSITION: 

NOTES: 


DATAFLOW  NAME: 

ALIASES: 

COMPOSITION: 

NOTES: 


DATAFLOW  NAME: 

ALIASES: 

COMPOSITION: 


NOTES: 


DATA  ELEMENT  NAME: 
ALIASES: 

VALUES  AND  MEANINGS: 


NOTES: 


DATA  ELEMENT  NAME: 
ALIASES: 

VALUES  AND  MEANINGS: 


NOTES : 


CMDR(FRMR) -RESPONSE 
NONE 

CMDR(FRMR) -RESPONSE  =  1100  +  FINAL-BIT 
+  001 

HDLC  PRIMARY,  SECONDARY  NODE  PROTOCOL 
LAYERS 


COMMAND-MODIFIER-BITS 

NONE 

COMMAND-MODIFIER-BITS  =  [DISC-COMMAND 
I  TRANSMITTED-SABM-COMMAND] 

EXECUTE  U-FRAME  COMMAND  LAYER 


CONTROL-FIELD 

NONE 

CONTROL-FIELD  =  [ I-FRAME-CONTROL-FIELD 
|  S-FRAME-CONTROL-FI ELD  ]  U-FRAME- 
CONTROL-FIELD] 

HDLC  PRIMARY,  SECONDARY  NODE  PROTOCOL 
LAYERS 


DISC-COMMAND 

NONE 

BITS  1,2,7  =  1 

BITS  3, 4, 6, 8  =  0 

COMMANDS  THE  SECONDARY  NODE  TO 

ENTER  THE  DISCONNECTED  STATE 

EXECUTE  U-FRAME  COMMAND  LAYER 


DISC-UA-RESPONSE 

NONE 

DISCONNECT  ACKNOWLEDGEMENT  RESPONSE 
BITS  1,2, 6, 7  =  1 
BITS  3,4,8  =  0 

ACKNOWLEDGES  TO  THE  PRIMARY  NODE  THAT 
THE  SECONDARY  NODE  IS  NOW  IN  THE 
DISCONNECTED  STATE- 
EXECUTE  U-FRAME  COMMAND  LAYER, 

WINDOW  SECONDARY  INFORMATION  BLOCKS 
LAYER 
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DATA  ELEMENT  NAME: 
ALIASES: 

VALUES  AND  MEANINGS: 


NOTES: 


DM-RESPONSE 

NONE 

BITS  1-4  =  1 
BITS  6,7,8  =  0 

INDICATES  THAT  THE  SECONDARY  NODE  IS 
IN  THE  DISCONNECTED  MODE  AND  CANNOT 
RECEIVE  LEVEL-2- PACKETS  EXCEPT  FOR  A 
SABM-COMMAND 

EXECUTE  U-FRAME  RESPONSE,  COMMAND  LAYER 
AND  WINDOW  SECONDARY  INFORMATION 
BLOCKS  LAYER 


DATA  ELEMENT  NAME: 
ALIASES: 

VALUES  AND  MEANINGS: 


NOTES : 


FCS-BLOCK 

NONE 

FIELD  CHECK  SEQUENCE  BLOCK 
A  SIXTEEN  BIT  SEQUENCE  GENERATED  AT 
THE  TRANSMITTING  NODE  THAT  IS  THE 
REMAINDER  AFTER  DIVISION  OF  THE  LEVEL- 
2-PACKET  BY  THE  CRC  POLYNOMIAL 
EXTRACT  VALID  PACKET  LAYER 


DATA  ELEMENT  NAME: 
ALIASES: 

VALUES  AND  MEANINGS: 


NOTES : 


FCS- ERROR- PACKET 
NONE 

A  VALID-LENGTH-PACKET  WHOSE  FCS-ELOCK 
DOES  NOT  MATCH  THE  LOCALLY -GENERATED- 
CRC- POLYNOMIAL 
EXTRACT  VALID  PACKET  LAYER 


DATA  ELEMENT  NAME: 
ALIASES: 

VALUES  AND  MEANINGS: 


NOTES: 


FINAL-BIT 

I -FRAME-FINAL-BIT,  S-FRAME-FINAL-BIT, 
U-FRAME-FINAL-BIT 

BIT  5  OF  THE  SECONDARY-FRAME-CONTROL- 
FIELD 

0  =  NOT  A  RESPONSE  TO  A  PRIMARY  NODE 
POLL 

1  =  THE  RESPONSE  TO  THE  PRIMARY  NODE 
POLL 

HDLC  PRIMARY  NODE  PROTOCOL  LAYER 


DATA  ELEMENT  NAME: 
ALIASES: 

VALUES  AND  MEANINGS: 
NOTES: 


I -FRAME -FINAL-BIT 
FINAL-BIT 
SEE  ALIAS 
EXECUTE  SECONDARY 


-FRAME  PACKET  LAYER 
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DATAFLOW  NAME: 
ALIASES: 

COMPOSITION : 

MOTES : 


DATA  ELEMENT  NAME: 
ALIASES: 

VALUES  AND  MEANINGS: 
NOTES: 


DATA  ELEMENT  NAME: 
ALIASES: 

VALUES  AND  MEANINGS: 
NOTES: 


DATA  ELEMENT  NAME: 
ALIASES: 

VALUES  AND  MEANINGS: 
NOTES: 


DATA  ELEMENT  NAME: 
ALIASES: 

VALUES  AND  MEANINGS: 
NOTES: 


DATA  ELEMENT  NAME: 
ALIASES: 

VALUES  AND  MEANINGS : 


NOTES: 


I -FRAME -PACKET- SEQUENCE- INFO 
SECONDARY- I -FRAME-PACKET-SEQUENCE- INFO, 
PRIMARY -I -FRAME- PACKET- SEQUENCE -INFO 
I -FRAME- PACKET- SEQUENCE -INFO  =  N(R)  + 

N(S) 

KDLC  PRIMARY,  SECONDARY  NODE  PROTOCOL 
LAYERS 


I -FRAME-POLL- BIT 

POLL-BIT 

SEE  ALIAS 

EXECUTE  PRIMARY  I -FRAME  PACKET  LAYER, 
WINDOW  SECONDARY  INFORMATION  BLOCKS 
LAYFR 


INVALID-LENGTH-PACKET 
INVALID-LENGTH -PRIMARY -PACKET, 
INVALID-LENGTH -SECONDARY-PACKET 
ANY  UNSTUFFED-PACKET  THAT  IS  LESS  THAN 
32  BITS  LONG 

EXTRACT  VALID  PACKET  LAYER 


INVALID-LENGTH -PRIMARY -PACKET 
INVALID-LENGTH -PACKET 
SEE  ALIAS 

HDLC  SECONDARY  NODE  PROTOCOL  LAYER 


INVALID-LENGTH-SECONDARY-PACKET 

INVALID-LENGTH-PACKET 

SEE  ALIAS 

HDLC  PRIMARY  NODE  PROTOCOL  LAYER 


INVALID-SECONDARY-N ( R) -I -FRAME 
NONE 

ANY  S ECONDARY-TO-PR I MARY - 1 - FRAME  WITH 
AN  N (R)  THAT  IS  NOT  IN  THE  WINDOW  OF 
THE  PRIMARY  NODE 

HDLC  PRIMARY  NODE  PROTOCOL  LAYER 


DATA  ELEMENT  NAME: 
ALIASES: 

VALUES  AND  MEANINGS: 


NOTES: 


INVALID-PRIMARY-PACKET-TYPE 

NONE 

ANY  PRIMARY-LEVEL- 2- PACKET  THAT 
PASSES  THE  INITIAL  VALIDATION  IN  THE 
EXTRACT  VALID  PACKET  PROCESS  BUT 
CANNOT  BE  RECOGNIZED  AS  ANY  OF  THE 
LEGAL  PRIMARY  PACKET  TYPES 
HDLC  SECONDARY  NODE  PROTOCOL  LAYER 


DATA  ELEMENT  NAME: 
ALIASES: 

VALUES  AND  MEANINGS: 


NOTES: 


INVAL ID-SECONDARY -PACKET-TY  PE 
NONE 

ANY  SECONDARY -LEVEL- 2 -PACKET  THAT 
PASSES  THE  INITIAL  VALIDATION  IN  THE 
EXTRACT  VALID  PACKET  PROCESS  BUT 
CANNOT  BE  RECOGNIZED  AS  ANY  OF  THE 
LEGAL  SECONDARY  PACKET  TYPES 
HDLC  PRIMARY  NODE  PROTOCOL  LAYER 


DATA  ELEMENT  NAME: 
ALIASES: 

VALUES  AND  MEANINGS: 
NOTES : 


LEVEL- 2 -PACKET 
NONE 

THE  CONTENTS  BETWEEN  TWO  SYN  CHARACTERS 
EXCLUDING  THE  ABORTED  PACKETS 
EXTRACT  VALID  PACKET  LAYER 


DATA  ELEMENT  NAME: 
ALIASES: 

VALUES  AND  MEANINGS: 


NOTES: 


LINK-STATUS 

NONE 

INDICATES  THE  CURRENT  STATE  OF  THE 
LINK  BETWEEN  THE  PRIMARY  AND  SECONDARY 
NODES 

THE  STATE  OF  THE  LINK  MAY  BE  EITHER 
DISCONNECTED,  READY,  OR  PENDING-SETUP 
EXECUTE  U-FRAME  RESPONSE  LAYER, 

WINDOW  PRIMARY  INFORMATION  BLOCKS  LAYER 


DATA  ELEMENT  NAME: 
ALIASES: 

VALUES  AND  MEANINGS: 


MOTES : 


LOCAL LY-GENERATED-CRC- REMAINDER 
NONE 

A  SIXTEEN  BIT  SEQUENCE  THAT  IS  THE 
REMAINDER  AFTER  DIVISION  OF  THE  VALID- 
LENGTH-PACKET  BY  THE  CRC  POLYNOMIAL 
EXTRACT  VALID  PACKET  LAYER 
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DATA  ELEMENT  NAME: 
ALIASES: 

VALUES  AND  MEANINGS: 


NOTES: 


N{R) 

READY-N ( R) ,  BUSY-N(R),  REJECT-N (R) 

RECEIVE  SEQUENCE  NUMBER 

BITS  6,7,8  OF  THE  SECONDARY- I -FRAME- 

CONTROL-FIELD 

INDICATES  THE  NEXT  PACKET  THAT  THE 
SECONDARY  NODE  EXPECTS  TO  RECEIVE  FROM 
THE  PRIMARY  NODE 

HDLC  PRIMARY  NODE  PROTOCOL  LAYER 


DATA  ELEMENT  NAME: 
ALIASES: 

VALUES  AND  MEANINGS: 


NOTES: 


N(S) 

NONE 

SEND  SEQUENCE  NUMBER 

BITS  2,3,4  OF  THE  I-FRAME-CONTROL-FIELD 
HDLC  PRIMARY  AND  SECONDARY  NODES 
PROTOCOL  LAYERS 


DATA  ELEMENT  NAME: 
ALIASES: 

VALUES  AND  MEANINGS: 
NOTES: 


OUT-OF -SEQUENCE -PR I MARY- I -FRAME 
OUT-OF -SEQUENCE -PR I MARY -I -FRAME-PACKET 
SEE  ALIAS 

EXECUTE  PRIMARY  I -FRAME  PACKET 


DATA  ELEMENT  NAME: 
ALIASES: 

VALUES  AND  MEANINGS: 


NOTES: 


OUT-OF -SEQUENCE- PR I MARY -I -FRAME- PACKET 
NONE 

ANY  PRI MARY-TO-SECONDARY-I-FRAME  WITH 
AN  N(R)  THAT  IS  NOT  IN  THE  WINDOW  OF 
THE  SECONDARY  NODE 

HDLC  SECONDARY  NODE  PROTOCOL  LAYER 


DATA  ELEMENT  NAME: 
ALIASES: 

VALUES  AND  MEANINGS: 


NOTES: 


POLL-BIT 

I -FRAME-POLL- BIT,  S-FRAME-POLL-BIT , 
U-FRAME-POLL-BIT 

BIT  5  OF  THE  PRIMARY-FRAME-CONTROL- 
FIELD 

IF  THIS  BIT  IS  A  1  THEN  THE  PRIMARY 
NODE  IS  REQUESTING  A  STATUS  UPDATE 
FROM  THE  SECONDARY  NODE  ON  THE  VALUE 
OF  THE  WINDOWING  VARIABLES  AND  THE 
STATE  OF  THE  SECONDARY  NODE 
HDLC  SECONDARY  NODE  PROTOCOL  LAYER 


DATA  ELEMENT  NAME: 
ALIASES: 

VALUES  AND  MEANINGS: 


NOTES: 


PRIMARY-BUSY-INDI CATION 
NONE 

TWO-BIT  CODE  WITH  VALUE  =10 
INDICATES  THAT  THE  PRIMARY  NODE  IS 
NOT  READY  TO  RECEIVE  LEVEL- 2-PACKETS 
EXECUTE  S-FRAME  COMMAND  LAYER, 

WINDOW  SECONDARY  INFORMATION  BLOCKS  LAYER 


DATA  ELEMENT  NAME: 
ALIASES: 

VALUES  AND  MEANINGS: 
NOTES: 

DATAFLOW  NAME: 
ALIASES: 

COMPOSITION: 

NOTES: 


PR I MARY -BU  SY-N ( R) 

BU  SY  -PR  I  MARY  — N  ( R ) 

SEE  ALIAS 

WINDOW  SECONDARY  INFORMATION  BLOCKS 
LAYER 

PRIMARY-I-FRAME-CONTROL-FI ELD 
NONE 

PR I MARY -I -FRAME-CONTROL- FI ELD  =  0  + 

N ( S)  +  I -FRAME-POLL- BIT  +  N ( R) 
EXECUTE  PRIMARY  I-FRAME  PACKET  LAYER 


DATAFLOW  NAME: 
ALIASES: 
COMPOSITION: 
NOTES: 


PRIMARY-I-FRAME-PACKET 

PRI MARY -TO- SECONDARY-I -FRAME -PACKET 

SEE  ALIAS 

EXECUTE  PRIMARY  I-FRAME  PACKET 


DATA  ELEMENT  NAME: 
ALIASES: 

VALUES  AND  MEANINGS: 


NOTES: 


PRIMARY-I-FRAME-N (R) 

PR I MARY- I -FRAME- PACKET- SEQUENCE -INFO 
AN  INTEGER  BETWEEN  0  AND  7  INDICATING 
THE  NEXT  PACKET  SEQUENCE  NUMBER  THAT 
THE  PRIMARY  NODE  IS  EXPECTING  TO 
RECEIVE 

EXECUTE  PRIMARY  I-FRAME  PACKET  LAYER, 
WINDOW  SECONDARY  INFORMATION  BLOCKS 
LAYER 


DATA  ELEMENT  NAME: 
ALIASES: 

VALUES  AND  MEANINGS: 
NOTES : 


PR I MARY -I -FRAME- PACKET- SEQUENCE- INFO 
PRIMARY-I-FRAME-N (R) 

SEE  ALIAS 

HDLC  SECONDARY  NODE  PROTOCOL  LAYER 


DATAFLOW  NAME: 

ALIASES: 

COMPOSITION: 


NOTES: 


PRIMARY-INCOM ING-BIT- STREAM 
NONE 

PRIMARY-INCOMING-BIT-STREAM  = 

{ { SYN }  +  TRAN  SMITTED-SECONDARY-LEVEL-2- 
PACKET} 

OVERVIEW  LAYER 
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DATAFLOW  NAME: 

ALIASES: 

COMPOSITION: 

NOTES: 


PR I MARY -LEVEL- 2 -PACKET 
NONE 

PRIMARY-LEVEL-2-rACKE?  =  ADDRESS-FIELD 
+  CONTROL-FIELD  +  (INFO-FIELD) 

FDLC  PRIMARY  NODE  PROTOCOL  LAYER 


DATA  ELEMENT  NAME: 
ALIASES: 

VALUES  AND  MEANINGS: 
NOTES: 


PRIMARY-LEVEL-3 -PACKET 
PRIMARY-NODE- LEVEL-3 -PACKET 
SEE  ALIAS 

WINDOW  PRIMARY  INFORMATION  BLOCKS 
LAYER 


DATA  ELEMENT  NAME: 
ALIASES: 

VALUES  AND  MEANINGS: 
NOTES: 


PRIMARY-NODE-LEVEL-3 -PACKET 
PRIMARY-LEVEL-3 -PACKET 
ANY  LEVEL  3  PACKET  AT  A  NODE  THAT  HAS 
BEEN  DESIGNATED  AS  A  PRIMARY  NODE 
OVERVIEW  LAYER 


DATAFLOW  NAME: 

ALIASES: 

COMPOSITION: 


NOTES: 


PRIMARY-NODE-STATUS 

NONE 

PRIMARY-NODE-STATUS  =  [READY- 
INDICATION  +  READY-N ( R)  I  BUSY- 
INDICATION  +  BUSY-N  ( R)  I  REJECTION- 
EXCEPTION-CONDITION  +  REJ  ECT-N ( R) ] 

+  S-FRAME-POLL-BIT 
FDLC  SECONDARY  NODE  PROTOCOL  LAYER 


DATA  ELEMENT  NAME: 
ALIASES: 

VALUES  AND  MEANINGS: 


NOTES: 


PRIMARY-N (R) 

PEADY-PRIMARY-N ( R) ,  BUSY -PRI MARY -N ( R) , 
REJ  ECT- PR I  MAR Y -N ( R ) 

RECEIVE  SEQUENCE  NUMBER 

BITS  6 , 7 , R  OF  THE  PR  I  MARY - 1 -FRAME- 

CONTROL-FIELD 

INDICATES  THE  NEXT  PACKET  THAT  THE 
PRIMARY  NODE  EXPECTS  TO  RECEIVE  FROM 
THE  SECONDARY  NODE 

FDLC  SECONDARY  NODE  PROTOCOL  LAYER 


DATAFLOW  NAMF : 

ALIASES: 

COMPOSITION: 


NOTES: 


PRIMARY-OUTGOING-BIT-STREAM 

NONE 

PRIMARY-OUTGOING-BIT-STREAM  = 

{ { SYN }  +  TRANSM ITTHD-SECONDAPY- 
LEVEL- 2 -PACKET} 

OVERVIEW  LAYER 
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DATA  ELEMENT  NAME: 
ALIASES: 

VALUES  AND  MEANINGS: 


NOTES: 


DATA  ELEMENT  NAME: 
ALIASES: 

VALUES  AND  MEANINGS: 
NOTES : 


DATA  ELEMENT  NAME: 
ALIASES: 

VALUES  AND  MEANINGS: 
NOTES : 


DATA  ELEMENT  NAME: 
ALIASES: 

VALUES  AND  MEANINGS: 


NOTES: 


DATAFLOW  NAME: 

ALIASES: 

COMPOSITION: 


NOTES: 


DATA  ELEMENT  NAME: 
ALIASES: 

VALUES  AND  MEANINGS: 


NOTES: 


PRIMARY -READY -INDICATION 
NONE 

TWO  BIT  CODE  WITH  VALUE  =  00 
INDICATES  '’’HAT  THE  PRIMARY  NODE  IS 
READY  TO  RECEIVE  LEVEL -2- PACKETS 
EXECUTE  S -FRAME  COMMAND  LAYER, 
WINDOW  SECONDARY  INFORMATION  BLOCKS 


PRIMARY-READY-N (R) 

READY-PRIMARY-N (R) 

SEE  ALIAS 

WINDOW  SECONDARY  INFORMATION  BLOCKS 
LAYER 


PRIMARY -RE J  ECT-N ( R) 

PRIMARY -N(R) 

SEE  ALIAS 

EXECUTE  S-FRAME  COMMAND  LAYER, 

WINDOW  SECONDARY  INFORMATION  BLOCKS  LAYER 


PRIMARY-REJECTION-CONDITION 

NONE 

TWO-BIT  CODE  WITH  VALUE  -  01  THAT 
INDICATES  THAT  THE  SECONDARY-V( S)  IS  TO 
BE  RESET  TO  THE  N  ( R)  IN  THE  REJ- 
COMMAND  AND  ALL  PACKETS  SUBSEQUENT  TO 
THAT  PACKET  NUMBER  RETRANSMITTED 
EXECUTE  S-FRAME  COMMAND  LAYER, 

WINDOW  SECONDARY  INFORMATION  BLOCKS  LAYFR 


PRI MARY-TO-SECONDARY-I-FRAME-TACKET 
PR I MARY- I -FRAME-PACKET 
PRIMARY-TO-SECONDARY-I-FRAME  = 

[ INVALID-PRIMARY-I-FRAME  I  VALID- 
rRIMARY-I-FRAME-PACKET] 

HDI.C  SECONDARY  NODE  PROTOCOL  LAYER 


READY-INDICATION 

NONE 

TWO  BIT  CODE  WITH  VALUE  =  00 
INDICATES  THAT  THE  SECONDARY  NODE  IS 
READY  TO  RECEIVE  LEVEL- 2-PACKETS 
EXECUTE  S-FRAME  RESPONSE  LAYFR, 
WINDOW  PRIMARY  INFORMATION  BLOCKS 


J 
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DATA  ELEMENT  NAME: 
ALIASES: 

VALUES  AND  MEANINGS: 


NOTES: 


DATA  ELEMENT  NAME: 
ALIASES: 

VALUES  AND  MEANINGS: 
NOTES: 


DATA  ELEMENT  NAME: 
ALIASES: 

VALUES  AND  MEANINGS: 
NOTES: 


DATAFLOW  NAME: 

ALIASES: 

COMPOSITION: 

NOTES : 


DATAFLOW  NAME: 

ALIASES: 

COMPOSITION: 

NOTES: 


DATA  ELEMENT  NAME: 
ALIASES: 

VALUES  AND  MEANINGS: 
NOTES : 


READY-N (R) 

N(R) 

SEE  ALIAS 

THE  PACKET  THAT  THE  SECONDARY  NODE 
IS  EXPECTING  TO  RECEIVE  NEXT 
EXECUTE  S-FRAME  RESPONSE  LAYER, 

WINDOW  PRIMARY  INFORMATION  BLOCKS  LAYER 


READY-PRIMARY-N (R) 

PRIMARY-N ( R) 

SEE  ALIAS 

EXECUTE  S-FRAME  COMMAND  LAYER, 
WINDOW  SECONDARY  INFORMATION  BLOCKS 


REJ-READY-INDI CATION 
NONE 

THIS  IS  A  SIGNAL  THAT  THE  REJECTION 
EXCEPTION  CONDITION  HAS  BEEN  CLEARED 
WINDOW  PRIMARY,  SECONDARY  INFORMATION 
BLOCKS  LAYERS 


REJ-COMMAND 

NON'' 

REJ-COMMAND  =  PRIMARY-REJECTION- 
CONDITION  +  REJECT-PRIMARY-N (R) 
EXECUTE  S-FRAME  COMMAND  LAYER 


REJ-RESPONSE 

NONE 

REJ-RESPONSE  =  REJECTION-EXCEPTION- 
CONDITION  +  REJECT-N(R) 

EXECUTE  S-FRAME  RESPONSE  LAYER 


REJECT-N  (R) 

N  ( R) 

SEE  ALIAS 

EXECUTE  S-FRAME  RESPONSE  LAYER, 

WINDOW  PRIMARY  INFORMATION  BLOCKS  LAYER 
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DATA  ELEMENT  NAME: 
ALIASES: 

VALUES  AND  MEANINGS: 


NOTES: 


DATA  ELEMENT  NAME: 
ALAISES : 

VALUES  AND  MEANINGS: 
NOTES: 


DATAFLOW  NAME: 

ALIASES: 

COMPOSITION: 


NOTES: 


DATAFLOW  NAME: 

ALIASES: 

COMPOSITION: 


NOTES: 


DATAFLOW  NAME: 

ALIASES: 

COMPOSITION: 

NOTES : 


DATAFLOW  NAME: 
ALIASES: 
COMPOSITION: 
NOTES: 


REJECTION-EXCEPTION-CONDITION 

NONE 

TWO-BIT  CODE  WITH  VALUE  =  01  THAT 
INDICATES  THAT  THE  PRIMARY-V(S)  IS  TO 
BE  RESET  TO  THE  N(R)  IN  THE  REJ- 
RESPONSE  AND  ALL  PACKETS  SUBSEQUENT  TO 
THAT  PACKET  NUMBER  RETRANSMITTED 
EXECUTE  S-FRAME  RESPONSE  LAYER, 

WINDOW  PRIMARY  INFORMATION  BLOCKS  LAYER 


RESET-COMMAND-PACKET 

SABM-COMMAND 

SEE  ALIAS 

WINDOW  PRIMARY  INFORMATION  BLOCKS 
LAYER 


RFSPONSE-MODIFI ER-BITS 
NONE 

RESPONSE-MODIFIER-BITS  =  [DM-RESPONSE 
|  TRAN SMITTED-SECONDARY-CMDR ( FRMR) - 
RESPONSE  |  UA-RESPONSE] 

EXECUTE  U-FRAME  RESPONSE  LAYER 


RESPONSE-SUPERVISORY-FUNCTION-BITS 

NONE 

RESPONSE-SUPERVISORY-FUNCTION-BITS  = 
[RR-RESPONSE  |  RNR- RESPONSE  |  REJ- 
RESPONSE] 

EXECUTE  S-FRAME  RESPONSE  LAYER 


RNR-COMMAND 

NONE 

RNR-COMMAND  =  PRI MARY-BU SY-INDI CAT JON 
+  BUSY-PRIMARY -N ( R) 
EXECUTE  S-FRAME  COMMAND  LAYER 


RNR-RESPONSE 

NONE 

RNR-RESPONSE  =  BUSY-INDICATION  +  N ( R) 
EXECUTE  S-FRAME  RESPONSE  LAYER, 

WINDOW  SECONDARY  INFORMATION  BLOCKS 
LAYER 


DATAFLOW  NAME: 

ALIASES: 

COMPOSITION: 

NOTES: 


DATAFLOW  NAME: 
ALIASES: 
COMPOSITION: 
NOTES: 


DATAFLOW  NAME: 

ALIASES: 

COMPOSITION: 

NOTES: 


DATAFLOW  NAME: 

ALIASES: 

COMPOSITION: 


NOTES: 


DATA  ELEMENT  NAME: 
ALIASES: 

VALUES  AND  MEANINGS: 
NOTES: 


DATA  ELEMENT  NAME: 
ALIASES: 

VALUES  AND  MEANINGS: 
NOTES: 


PR-COMMAND 

NONE 

RR-COMMAND  =  PRI MARY-READY- INDI CATION 
+  RE  ADY-PRI  MARY-N  (  P.) 
WINDOW  PRIMARY  INFORMATION  BLOCKS, 
EXECUTE  S-FRAME  COMMAND  LAYER 
LAYER 


PR-RESPONSE 

NONE 

PR-RESPONSE  =  READY-INDICATION  +  N(F') 
EXECUTE  S-FRAME  RESPONSE  LAYER, 

WINDOW  SECONDARY  INFORMATION  BLOCKS 
LAYER 


S-FRAME-COMMAND 

NONE 

S-FRAME-COMMAND  =  S-FRAME-PCLL-BIT  + 
S-FRAME-CONTROL-FI ELD 
HDLC  SECONDARY  NODE  PROTOCOL  LAYER 


S-FRAME-CONTROL-FI ELD 
NONE 

S-FRAME-CONTROL-FI ELD  = 
(RR-COMMAND  1  RNR-COMMAND  I  FEJ- 
COMMAND] 

EXECUTE  S-FRAME  COMMAND  I, AYER 


S-FRAME- FINAL-BIT 

FINAL-BIT 

SEE  ALIAS 

EXECUTE  S-FRAME  RESPONSE  LAYER 


S-FRAME-rOLIi-RT  T 

POLL-BIT 

SEE  ALIAS 

EXECUTE  S-FRAMF,  COMMAND  LAYER, 
WINDOW  SECONDARY  INFORMATION  RLO(  KS 
LAYER 


DATAFLOW  NAME: 
ALIASES: 
COMPOSITION: 
NOTES: 


DATA  ELEMENT  NAME: 
ALIASES: 

VALUES  AND  MEANINGS: 


NOTES: 


DATA  ELEMENT  NAME: 

AL I  AS  ES : 

VALUES  AND  MEANINGS: 


NOTES: 


DATA  ELEMENT  NAME: 
ALIASES: 

VALUES  AND  MEANINGS: 


NOTES: 


DATAFLOW  NAME: 
ALIASES: 
COMPOSITION : 


S-FRAME-RESPONSE 

S ECONDAR Y -TO- PR I MAR Y-S- FRAME -RESPONSE 
SEE  ALIAS 

EXECUTE  S-FRAME  RESPONSE  LAYER 


SABM-COMMAND 

RESET-COMMAND-PACKET 

SET  ASYNCHRONOUS  BALANCED  MODE  COMMAND 
CONTROL-FIELD  =  1111  +  POLL-BIT  +  100 
RESETS  THE  LINK  TO  ENABLE  RECOVERY 
FROM  PROCEDURE  ERRORS  OR  INITIALIZATION 
OF  THE  LINK  AT  STARTUP 
HDLC  PRIMARY,  SECONDARY  NODE  PROTOCOL 
LAYERS 


SABM-UA-RESPONSE 

NONE 

SABM  ACKNOWLEDGEMENT  RESPONSE 
BITS  1,2, 6,7  =  1 
BITS  3,4,8  =  0 

CONFIRMS  TO  THE  PRIMARY  NODE  THAT  THE 
SECONDARY  NODE  HAS  NCW  RESET  ITS 
WINDOWING  VARIABLES  AND  IS  READY  TO 
RESTART  TRANSMISSION  OF  THE  LEVEL-2- 
PACKETS 

EXECUTE  U-FRAME  COMMAND  LAYFR, 

WINDOW  SECONDARY  INFORMATION  BLOCKS 
LAYER 


SECONDARY-FINAI.-BIT 

NONE 

0  =  THE  SECONDARY  LEVEL  2  PACKET  IS 
NOT  A  RESPONSE  TO  A  POLL  FROM 
THE  PRIMARY  NODE 

1  =  THE  SECONDARY  LEVEL  2  PACKET  IS 
A  RESPONSE  TO  A  POLL  FROM  THE 
PRIMARY  NODE 

WINDOW  SECONDARY  INFORMATION  BLOCKS 
LAYFR 


SECONDARY- 1 -FRAME-CONTROL-F I  ELD 
NONE 

SECONDARY  - 1 -  FRAMF.-CONTROL-FI  ELD  =  0  + 

N  (  S )  +  I  -  FRAMF.-F INAI.-BIT  +  N  (  R) 

EXECUTE  SECONDARY  I -FRAME  PACKET  LAYFR 


NOTES : 


DATAFLOW  NAME: 
ALIASES: 
COMPOSITION: 
NOTES: 


DATAFLOW  NAME: 
ALIASES: 
COMPOSITION: 
NOTES : 


DATAFLOW  NAME: 

ALIASES: 

COMPOSITION: 


NOTES: 


DATAFLOW  NAME: 

ALIASES: 

COMPOSITION: 

NOTES : 


DATA  ELEMENT  NAME: 
ALIASES: 

VALUES  AND  MEANING S: 
NOTES: 


DATA  ELEMENT  NAME: 
ALIASES: 

VALUES  AND  MEANINGS: 


NOTES: 


SECONDARY -I -FRAME-PACKET 
SECONDARY-TO-PRI MARY-I -FRAME-PACKET 
SEE  ALIAS 

EXECUTE  SECONDARY  I-FRAME  PACKET  LAYER 


SECONDARY- I-FRAME-PACKET-SEQUENCE- INFO 
I -FRAME-PACKET- SEQUENCE-INFO 
SEE  ALIAS 

EXECUTE  SECONDARY  I-FRAME  PACKET  LAYER 


SECONDARY-INCOM ING-BIT-STREAM 
NONE 

SECONDARY-INCOMING-BIT-STREAM  = 

{{SYN}  +  TRAN.3MITTED-PRIMARY-LEVEL-2- 
PACKET} 

OVERVIEW  LAYER 


SECONDARY-LEVEL- 2- PACKET 
NONE 

SECONDARY -LEVEL- 2 -PACKET  =  ADDRESS-FIFLD 
+  CONTROL-FIELD  +  (INFO-FIELD) 

HDLC  SECONDARY  NODE  PROTOCOL  LAYER 


SECONDARY-LEVEL-3 -PACKET 
SECONDARY-NODE-LEVEL-3 -PACKET 
SEE  ALIAS 

WINDOW  SECONDARY  INFORMATION  BLOCKS 
LAYER 


SECONDARY-NODE-LEVEL-3 -PACKET 
NONE 

ANY  LEVEL  3  PACKET  THAT  IS  TO  BE 
TRANSMITTED  FROM  A  SECONDARY  NODE  TO 
A  PRIMARY  NODE 
OVERVIEW  LAYER 


V 


DATAFLOW  NAME: 

ALIASES: 

COMPOSITION: 


NOTES: 


SECONDARY -NODE-STATUS 
NONE 

SECONDARY-NODL.-STATUS  =  [READY- 
INDICATION  +  READY-N  ( R)  |  BUSY- 
INDICATION  +  BUSY-N(R)  |  REJECTION- 
EXCEPTION-CONDITION  +  REJ ECT-N ( R)  ] 

+  S-FRAME-FINAL-BIT 
FDLC  PRIMARY  NODE  PROTOCOL  LAYER 


DATAFLOW  NAME: 

ALIASES: 

COMPOSITION: 

NOTES: 


SECONDARY-OUTGOING-BIT-STREAM 

NONE 

SECONDARY-OUTGOING-BIT-STREAM  = 
{{SYN}  +  SECONDARY -LEVEL- 2- PACKET} 
OVERVIEW  LAYER 


DATAFLOW  NAME: 

ALIASES: 

COMPOSITION: 


NOTES: 


SECONDARY -TO-PRI MARY - I -FRAME 
SECONDARY- I-FRAME-PACKET 
SECONDARY -TO-PRI MARY -I -FRAME  = 
[INVALID-SECONDARY-I-FRAME  |  VALID¬ 
SECONDARY  -I-FRAME-PACKET] 

FDLC  PRIMARY  NODE  PROTOCOL  LAYER 


DATAFLOW  NAME: 

ALIASES: 

COMPOSITION: 


NOTES: 


SECONDARY-TO-PRIKARY-S-FRAME-RESPONSE 

S-FRAME-RESPONSE 

SECONDARY -TO-PRI MARY -S-FRAME-RESPONSE= 
S-FRAME-FINAL-BIT  +  RESPONSE- 
SUPERVISORY-FUNCTION-BITS 
FDLC  PRIMARY  NODE  PROTOCOL  LAYER 


DATAFLOW  NAME: 

ALIASES: 

COMPOSITION: 


NOTES: 


S ECONDAR Y -TO - PR I M ARY -U- FRAME -RESPONSE 
U-FRAME-RESPONSE 

S ECONDAR Y- TO- PR I MARY -U- FRAME- RES PON SE= 
RESPONSE-MODIFIER-BITS  +  U-FRAME- 
FINAL-BIT 

FDLC  PRIMARY  NODE  PROTOCOL  LAYER 


DATALOW  NAME: 

ALIASES: 

COMPOSITION: 

NOTES: 


SECONDARY -VALID-PACKET 
NONE 

SECONDARY-VALID-PACKET  =  ADDRESS-FIELD 
+  CONTROL-FIELD  +  ( INFO-FIELD) 

FDLC  PRIMARY  NODE  PROTOCOL  LAYER 
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DATA  ELEMENT  NAME: 
ALIASES: 

VALUES  AND  MEANINGS: 
NOTES: 


SYN 

NONE 

SYNCHRONIZATION  CHARACTER 
THE  OCTET  (01111110) 
OVERVIEW  LAYER 


DATA  ELEMENT  NAME: 
ALIASES: 

VALUES  AND  MEANINGS: 


NOTES: 


TRAN SM I TTED-PR I MARY -NODE- LEVEL- 3 -PACKET 
NONE 

ANY  LEVEL  3  PACKET  THAT  HAS  BEEN 
TRANSMITTED  FROM  A  PRIMARY  NODE  TO  A 
SECONDARY  NODE 
OVERVIEW  LAYER 


DATA  ELEMENT  NAME: 
ALIASES: 

VALUES  AND  MEANINGS: 


NOTES: 


TR AN SM ITTED-SABM-COMMAND 
NONE 

TRANSMITTED  SET  AN SYNCHRONOU S  BALANCED 

MODE  COMMAND 

BITS  1 ,2, 3, 4, 6  =  1 

BITS  7,8  =  0 

COMMANDS  THE  SECONDARY  NODE  TO  RESET 
THE  LINK  WINDOWING  VARIABLES 
EXECUTE  U-FRAME  COMMAND  LAYER 


DATA  ELEMENT  NAME: 
ALIASES: 

VALUES  AND  MEANINGS : 


NOTES: 


TRAN  SMITTED-SECONDAP.Y-CMDR  (  FRMR)  - 
RESPONSE 
NONE 

BITS  1 ,2,3,8  =  1 
BITS  4,6,7  =  0 

INDICATES  THAT  A  LOCAL  PROCEDURE  ERROR 
HAS  OCCURRED  AT  THE  SECONDARY  NODE  AND 
REQUESTS  THE  PRIMARY  NODE  TO  RESET  THE 
LINK 

EXECUTE  U-FRAME  RESPONSE  I, AYER 


DATA  ELEMENT  NAME: 
ALIASES: 

VALUES  AND  MEANINGS: 
NOTES: 


TRAN SM I TTED-SECONDARY -LEVEL- 3 -PACKET 
TRAN SMITTED-SECONDARY -NODE-LEVEL-3  - 
PACKET 
SEE  ALIAS 

EXECUTE  SECONDARY  I -FRAME  PACKET  LAYFR 


DATA  ELEMENT  NAME: 
ALIASES: 

VALUES  AND  MEANINGS: 


NOTES: 


DATAFLOW  NAME: 

ALIASES: 

COMPOSITION: 

NOTES: 


DATA  ELEMENT  NAME: 
ALIASES: 

VALUES  AND  MEANINGS: 
NOTES: 


DATA  ELEMENT  NAME: 
ALIASES: 

VALUES  AND  MEANINGS: 
NOTES: 


DATAFLOW  NAME: 

ALIASES: 

COMPOSITION: 

NOTES: 


DATAFLOW  NAME: 
ALIASES: 
COMPOSITION: 
NOTES: 


TRAN SM I TTED-SECONDARY -NODE-LEVEL- 3- 
PACKET 

TRAN SMITTED-SECONDARY-LEVEL-3 -PACKET 
ANY  LEVEL  3  PACKET  THAT  HAS  BEEN 
TRANSMITTED  FROM  A  PRIMARY  NODE  TO  A 
SECONDARY  NODE 
OVERVIEW  LAYER 


U-FRAME-COMMAND 

NONE 

U-FRAME-COMMAND  =  COMMAND-MODIFIER- 
BITS  +  U-FRAME-POLL-BIT 
HDLC  SECONDARY  NODE  PROTOCOL  LAYER 


U-FRAME-F INAL-BIT 

FINAL-BIT 

SEE  ALIAS 

EXECUTE  U-FRAME  RESPONSE  LAYER 


U-FRAME-POLL-BIT 
POLL- BIT 
SEE  ALIAS 

EXECUTE  U-FRAME  COMMAND  LAYER, 
WINDOW  SECONDARY  INFORMATION  BLOCKS 
LAYER 


U-FRAME-RESET-COMMAND 

NONE 

U-FRAME-RESET-COMMAND  =  [ SABM-COMMAND 
I  LINK-STATUS]  +  U-FRAME-FINAL-BIT 
HDLC  PRIMARY  NODE  PROTOCOL  LAYER 


U-FRAME-RESPONSE 

SECONDARY -TO- PRIMARY -U-FRAME -RESPONSE 
SEE  ALIAS 

EXECUTE  U-FRAME  RESPONSE  LAYER 
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DATA  ELEMENT  NAME: 
ALIASES: 

VALUES  AND  MEANINGS: 


NOTES: 


UA-RESPONSE 

NONE 

BITS  1,2, 6, 7  =  1 
BITS  3,4,8  =  0 

INDICATES  THAT  THE  COMMAND  SENT  BY  THE 
PRIMARY  NODE  HAS  BEEN  EXECUTED 
EXECUTE  U-FRAME  RESPONSE  LAYER 


DATAFLOW  NAME: 

ALIASES: 

COMPOSITION: 

NOTES: 


UN STUFFED-PACKET 
NONE 

UNSTUFFED-PACKET  =  [VALID-LENGTH- 
PACKET  |  INVALID-LENGTH-PACKET] 
EXTRACT  VALID  PACKET  LAYER 


DATA  ELEMENT  NAME: 
ALIASES: 

VALUES  AND  MEANINGS: 


NOTES: 


UPDATED -LOWER-WINDOW- EDGE 
NONE 

THIS  IS  AN  INTEGER  BETWEEN  0  AND  7 
THAT  IS  ONE  GREATER  THAN  THE  HIGHEST 
PACKET  SEQUENCE  NUMBER  THAT  CAN  BE 
SENT  UNTIL  THE  LOWER-WINDOW-EDGE  IS 
AGAIN  UPDATED 

WINDOW  PRIMARY,  SECONDARY  INFORMATION 
BLOCKS  LAYERS 


DATAFLOW  NAME: 

ALIASES: 

COMPOSITION: 

NOTES: 


VALID-LENGTH-PACKET 

NONE 

VALID-LENGTH -PACKET  =  FCS-ELOCK  + 
[ FCS-ERROR-PACKET  |  VALID-PACKET] 
EXTRACT  VALID  PACKET  LAYER 


DATAFLOW  NAME; 
ALIASES: 

COMPOSITION: 

NOTES: 


VALID-PACKET 
VALID-PRIMARY-PACKET, 
SECONDARY -VALID-PACKET 
SEE  ALIASES 

EXTRACT  VALID  PACKET  LAYER 


DATAFLOW  NAME: 

ALIASES: 

COMPOSITION: 


NOTES: 


VALID-PRIMARY -I -FRAME-PACKET 
NONE 

VAL ID-PRIMARY -I -FRAME- PACKET  = 

TRAN SMITTED-PRI MARY -NODE- LEVEL-3 -PACKET 
+  PR I MARY- 1 -FRAME -CONTROL -FI  ELD 
EXECUTE  PRIMARY  I-FRAME  PACKET  LAYER 


DATALOW  NAME: 

ALIASES: 

COMPOSITION: 

NOTES : 


VALID-PRIMARY-PACKET 

NONE 

VALID-PRIMARY-PACKET  =  ADDRESS-FIELD 
+  CONTROL-FIELD  +  (INFO-FIELD) 

HDLC  SECONDARY  NODE  PROTOCOL  LAYER 


DATAFLOW  NAME: 

ALIASES: 

COMPOSITION: 


NOTES: 


VALID-SECONDARY -I -FRAME-PACKET 
NONE 

VALID-SECONDARY -I -FRAME-PACKET  = 
TRANSMITTED-SECONDARY-I-FRAME-PACKET 
+  SECONDARY-I-FRAME-CONTROL-FI ELD 
EXECUTE  SECONDARY  I -FRAME  PACKET  LAYER 


DATAFLOW  NAME: 

ALIASES: 

COMPOSITION: 


NOTES: 


WINDOWED-I -FRAME 
NONE 

WIN DOW ED- 1 -FRAME  =  LEVEL-3  - 
PACKET  +  N(R)  +  N ( S)  +  [POLL-BIT 
I  FINAL-BIT] 

WINDOW  PRIMARY,  SECONDARY  INFORMATION 
BLOCKS  LAYER 
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FILE  DEFINITIONS 


FILE  OR  DATABASE  NAME: 
ALIASES: 

COMPOSITION : 

ORGANIZATION: 

NOTES: 


PENDING-  STATE-CHANGE 
NONE 

PENDING-STATE-CHANGE  =  [DISCONNECT- 
LINK  |  SETUP-LINK] 

SINGLE  VARIABLE 

EXECUTE  U-FRAME  RESPONSE  LAYER 


FILE  OR  DATABASE  NAME: 
ALIASES: 

COMPOSITION: 


ORGANIZATION: 

NOTES: 


PR I MARY -V ( R) 

NONE 

PRIMARY -V(R)  IS  THE  NEXT  PACKET 
EXPECTED  NUMBER 
IT  CAN  RANGE  FROM  0  TO  7 
SINGLE  VARIABLE 

EXECUTE  SECONDARY  I -FRAME  PACKET  LAYER 


FILE  OR  DATABASE  NAME: 
ALIASES: 

COMPOSITION: 


ORGANIZATION: 

NOTES: 


PRIMARY -V(S) 

NONE 

PR I MARY -V ( S)  IS  AN  INTEGER  BETWEEN 
0  AND  7  THAT  INDICATES  THE  SEQUENCE 
NUMBER  OF  THE  NEXT  I -FRAME  TO  BE  SENT 
SINGLE  VARIABLE 

WINDOW  PRIMARY  INFORMATION  BLOCKS 
LAYER 


FILE  OR  DATABASE  NAME: 
ALIASES: 

COMPOSITION: 


ORGANIZATION: 

NOTES: 


SECONDARY -V ( R) 

NONE 

SECONDARY -V(R)  IS  THE  NEXT  PACKET 
EXPECTED  NUMBER 
IT  CAN  RANGE  FROM  0  TO  7 
SINGLE  VARIABLE 

HDLC  SECONDARY  NODE  PROTOCOL  LAYER 
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FILE  OR  DATABASE 

ALIASES: 

COMPOSITION: 


ORGANIZATION: 

NOTES: 


NAME:  SECONDARY-V(S) 

NONE 

SECONDARY -V(S)  IS  AN  INTEGER  BETWEEN 
0  AND  7  THAT  INDICATES  THE  SEQUENCE 
NUMBER  OF  THE  NEXT  I-FRAME  TO  BE  SENT 
SINGLE  VARIABLE 

WINDOW  SECONDARY  INFORMATION  BLOCKS 
LAYER 


PROCESS  SPECIFICATIONS 


PROCESS  NAME:  EXTRACT  INFORMATION  BETWEEN  FLAGS 

PROCESS  NUMBER:  1.1. I 

PROCESS  DESCRIPTION: 

Strip  off  first  SYN  (flag  character) 

WThile  SYN  and  A30RT  not  encountered,  assemble  LEVEL-2-PACKET 
If  ABORT  encountered  then  discard  partially  assembled 
LEVEL- 2-PACKET  as  an  ABORTED-PACKET 
Else  output  LEVEL -2 -PACKET  when  second  SYN  is  encountered 


PROCESS  NAME:  UNSTUFF  0'S 

PROCESS  NUMBER:  1.1.2 

PROCESS  DESCRIPTION: 

Whenever  five  consecutive  l's  are  followed  by  a  0 , 
delete  the  0  from  the  LEVEL- 2-PACKET 
Output  the  new  packet  as  an  UNSTUFFED-PACKET 


PROCESS  NAME:  CHECK  LENGTH 

PROCESS  NUMBER:  1.1 .3 

PROCESS  DESCRIPTION: 

If  UNSTUFFED-PACKET  is  less  than  32  bits  long  then  it  is  an 
INVALID-LENGTH-PACKET 
Else  it  is  a  VALID-LENGTH-PACKET 


PROCESS  NAME:  GENERATE  CRC  REMAINDER 

PROCESS  NUMBER:  1.1. A 

PROCESS  DESCRIPTION: 

Divide  the  VALID-LENGTH-PACKET  by  the  CRC  polynomial  which 
is  x**16  +  x**12  +  x**5  +  1  modulo  2 
Multiply  the  VALID-LENGTH-PACKET  by  x**16  and  then  divide  it 
by  the  CRC  polynomial 

Add  the  remainders  of  the  above  two  operations  on  the 

VALID-LENGTH-PACKET  modulo  2  and  take  the  l's  complement 
Output  the  result  as  the  LOCALLY -GENE RATED -CRC- POLYNOMIAL 


PROCESS  NAME:  CHECK  FCS  BLOCK 

PROCESS  NUMBER:  1.1.5 

PROCESS  DESCRIPTION: 

If  the  FCS-BLOCK  and  the  LOCALLY -GEN ERATED-CRC- POI.YNOM I AL 
are  equal  then  the  VALID-LENGTH -PACKET  is  a  VALID-PACKET 
Else  it  is  a  FCS -ERROR- PACKET 


PROCESS  NAME:  DECODE  SECONDARY  PACKET  ADDRESS  AND 

CONTROL  FIELDS 
PROCESS  NUMBER:  1.2 

PROCESS  DESCRIPTION: 

If  ADDRESS-FIELD  is  (10000000)  then 
if  Bit  1  of  CONTROL-FIELD  =  0 

then  SECONDARY-VALID-PACKET  is  SECONDARY -TO- PR I MARY -I -FRAME 
else  if  Pit  2  of  CONTROL-FIELD  =  0 

then  SECONDARY-VALID-PACKET  is  SECONDARY -TO- PR I MARY -S- 
FRAME-RESPONSE 

else  SECONDARY-VALID-PACKET  is  SECONDARY -TO- PR  I  MAR Y-U- FRAME- 
RESPONSE 

Else  SECONDARY-VALID-PACKET  is  an  INVALID-SECONDARY-PACKET- 
TYPE 


PROCESS  NAME:  VALIDATE  I -FRAME  PACKET 

PROCESS  NUMBER:  1.3.1 

PROCESS  DESCRIPTION: 

If  N ( S )  Of  the  SECONDARY- I-FRAME -PACKET  =  PR I MARY-V ( R) 
then  the  SECONDARY- 1 -FRAME -PACKET  is  a  VAL I  D-SECONDARY - 
I -FRAME- PACKET 

Else  it  is  an  INVAL ID-SECONDARY-N { R) -I-FRAME 


PROOF SS  NAME:  PARSE  I -FRAME 

PROCESS  NUMBER:  1.3.2 

PROCESS  DESCRIPTION: 

Output  the  first  octet  of  the  VALID-SECONDARY-I-FRAME  as  the 
SECONDARY - 1 - FRAME-CONTROL- F I  ELD 
Output  Bit.  5  of  the  first  octet  of  the  VAL1 P-SEOONDARY- 1  - 
FRAME  as  the  I -FRAME-FINAL-BIT 
Output  all  octets  following  the  first  octet  as  the 
TRAN  SMI TTED-SECONDARY- I.EVEL-3 -PACKET 


PROCESS  NAME: 

PROCESS  NUMBER: 
PROCESS  DESCRIPTION: 
Output  Bits  2,3,4  as 
Output  Bits  6,7,P  as 


PARSE  I-FRAME  CONTROL  T I FLD 
1.3.3 


N(S) 
N  ( P ) 
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PROCESS  NAME:  PARSE  S-FRAME  RESPONSE  CONTROL  FIELD 

PROCESS  NUMBER:  1.4.1 

PROCESS  DESCRIPTION: 

RESPONSE-SUPERVISORY-FUNCTION-BITS  =  Bits  3, 4, 6, 7, 8  of 
S-FRAME-RESPONSE-CONTROL-FIELD 
S-FRAME-FINAL-BIT  =  Bit  5  of  S-FRAME -CONTROL-FIELD 


PROCESS  NAME:  DECODE  RESPONSE  SUPERVISORY  BITS 

PROCESS  NUMBER:  1.4.2 

PROCESS  DESCRIPTION: 

Case  Bits  3,4  of 

00:  RR-RESPONSE 

10:  RNR-RESPONSE 

01 :  REJ-RESPONSE 

1 1 :  INVALID-S-FRAME-RESPONSE 


PROCESS  NAME:  SEND  READY  STATUS  AND  EXTRACT  N ( R) 

PROCESS  NUMBER:  1.4.3 

PROCESS  DESCRIPTION: 

Output  READY-INDICATION 

Set  READY-N ( R)  =  Bits  6,7,8  of  RR-RESPONSE 


PROCESS  NAME:  SEND  BUSY  STATUS  AND  EXTRACT  N ( R) 

PROCESS  NUMBER:  1.4.4 

PROCESS  DESCRIPTION: 

Output  BUSY-INDICATION 

Set  BUSY-N(R)  =  Bits  6,7,8  of  RNR-RESPONSE 


PROCESS  NAME:  SEND  REJECT  CONDITION  AND  EXTRACT  N (R) 

PROCESS  NUMBER:  1.4.5 

PROCESS  DESCRIPTION: 

Output  REJECTION-EXCEPTION-CONDITION 

Set  REJECT-N ( R)  =  Bits  6,7,8  of  REJ-RESPONSE 


PROCESS  NAME:  PARSE  U-FRAME  RESPONSE  CONTROL  FIELD 

PROCESS  NUMBER:  1.5.1 

PROCESS  DESCRIPTION: 

FESPONSE-MODIFI ER-BITS  =  Bits  3, 4, 6, 7, 8  of  the  U-FRAME- 

RESPONSE 

U-FRAME-FINAL-BIT  =  Bit  5  of  the  U-FRAME-RESPONSE 
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PROCESS  NAME:  DECODE  RESPONSE  MODIFIER  BITS 

PROCESS  NUMBER:  1.5.2 

PROCESS  DESCRIPTION: 

Case  Bits  3, 4, 6, 7,8  of 

(11000):  Output  DM-RESPONSE 

(10001):  Output  CMDR(FRMR) -RESPONSE 

(00110):  Output  UA-RESPONSE 
otherwise:  Output  IN VALID-U-FRAME- RESPONSE 


PROCESS  NAME:  SET  UP  LINK 

PROCESS  NUMBER:  1.5.3 

PROCESS  DESCRIPTION: 

If  DM-RESPONSE  or  TRAN SMITTED-SECONDARY-CMDR ( FRMR ) -RESPONSE 
is  received  then  output  an  SABM-COMMAND  and  set  the 
PENDING- STATE-CHANGE  to  LINK-SETUP  state 


PROCESS  NAME:  EXECUTE  PENDING  STATE  CHANGE 

PROCESS  NUMBER:  1.5.4 

PROCESS  DESCRIPTION: 

If  UA-RESPONSE  is  received  then  set  LINK-STATUS  to  PENDING- 
STATE-CHANGE 


PROCESS  NAME:  RESET  V(S) 

PROCESS  NUMBER:  1.6.1 

PROCESS  DESCRIPTION: 

When  a  REJECTION-EXCEPTION-CONDITION  is  received 
Update  PRIMARY -V ( S)  to  equal  the  REJECT-N(R) 
Output  a  REJ -READY-INDICATION 


PROCESS  NAME:  UPDATE  LOWER  WINDOW  EDGE 

PROCESS  NUMBER:  1.6.2 

PR  OCE  S  S  DF,  S .  ''  'i  PT I  ON  : 

Set  UPDATED- f/)WER-WINDOW-EDGF,  =  N  (  R) 


PROCESS  NAME:  POLL  SECONDARY  FOR  READY  STATI 

PROCESS  NUMBER:  1.6.3 

PROCESS  DESCRIPTION: 

If  BUSY-INDICATION  is  received  then  after  POLL-DELAY  output 
an  RR-COMMAND 


PROCESS  NAME:  PLACE  I-FRAME  IN  X.25  LINK  QUITE 

PROCESS  NUMBER:  1.6.4 

PROCESS  DESCRIPTION: 

While  LINK-STATUS  is  in  READY  state 

and  PRIMARY-V ( S)  <  UPDATED-LOWER-WINDOW-EDGE  -  1 
and  no  RE J- READY -INDICATION  is  present 

Send  PR I MARY -LEVEL-3 -PACKET  as  WINDOW ED- I -FRAME 
with  N ( R)  =  PRIMARY-V ( R) 

N ( S)  =  PRIMARY-V ( S) 

Increment  PRIMARY -V(S) 

If  REJ- READY -INDICATION  then 

Retransmit  PRIMARY-LEVEL-3-PACKETs  starting  with  the 
WIN DOW ED- I -FRAME  with  N(S)  =  PRIMARY -V(S) 
Increment  PRIMARY-V(S) 


PROCESS  NAME:  SELECT  PACKET  FOR  X.2  5  LINK 

PROCESS  NUMBER:  1.6.5 

PROCESS  DESCRIPTION: 

S  1  ect  packets  from  the  transmit  queue  according  to  the 
following  priority 

Priority  1:  SABM-COMMAND  or  RESET-COMMAND-PACKET 

Priority  2:  RR-COMMAND 

Priority  3:  WINDOW ED- I -FRAME 

If  the  queue  is  empty  for  MAX-TIME-BETWEEN-UPDATES  then  send 
an  RR-RESPONSE  with  N ( R)  =  PRIMARY -N(R)  to  update 
SECONDARY  NODE  LOW ER-W INDOW- EDG F. 

Generate  FCS-BLOCK 

Divide  the  VALID-LENGTU-PACKET  by  the  CRC  polynomial  which 
is  x **16  +  x**12  +  x**5  +  1  modulo  2 
Multiply  the  VALID-LENGTH -PACKET  by  x**16  and  then  divide 
it  by  the  CRC  polynomial 

Add  the  remainders  of  the  above  two  operations  on  the 

VALID-LENGTH-PACKET  modulo  2  and  take  the  1's  complement 
The  result  is  the  FCS-BLOCK 

Append  the  FCS-BLOCK  to  the  packet  to  be  transmitted  and 
output  the  combination  as  a  PR I  MARY -LEVEL- 2 -PACKET 


PROCESS  NAME:  RECOVER  FROM  PROCEDURE  ERROR 

PROCESS  NUMBER:  1.7 

PROCESS  DESCRIPTION: 

If  an  INVALID-LENGTH-SECONDARY-PACKET  or  an  INVALID- 
SECONDARY-PACKET-TYPE  or  an  INVAL I  D-SECONDARY  -N  ( I: )  - 1  -  FRAME 
then  reset  the  link  using  an  SABM-COMMAND 
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PROCESS  NAME:  SEND  PACKET 

PROCESS  NUMBER:  1.8 

PROCESS  DESCRIPTION: 

Send  continuous  SYNs  while  there  are  no  LEVEL-2-PACKETs  to 
transmit 

When  a  LEVEL-2-PACKET  is  available,  add  a  SYN  to  the  front 
of  the  packet  and  another  SYN  to  the  rear  of  the  packet  and 
insert  it  into  the  outgoing  bit  stream 


PROCESS  NAME:  TRANSMIT  BIT  STREAMS 

PROCESS  NUMBER:  2 

PROCESS  DESCRIPTION: 

Use  the  Physical  Level  Protocol  to  transmit  the  PRIMARY- 
OUTGOING-BIT-STREAM  to  the  SECONDARY  NODE  and  the  SECONDARY¬ 
OUTGOING-BIT-STREAM  to  the  PRIMARY  NODE 


PROCESS 

NAME: 

EXTRACT  VALTD  PACKET 

PROCESS 

NUMBER: 

3.1 

PROCESS 

DESCRIPTION: 

SEE  PROCESSES  1.1.1  THROUGH  1.1.3 

PROCESS 

NAME: 

DECODE  PRIMARY  PACKET  ADDRESS  AND 
CONTROL  FIELDS 

PROCESS 

PROCESS 

NUMBER: 

DESCRIPTION: 

3.2 

If  ADDRESS-FIELD  is  (10000000)  then 
if  Bit  1  of  CONTROL-FIELD  =  0 

then  VALID-PRIMARY-PACKET  is  an  PRIMARY-TO-SECONDARY-I- 
FRAME-PACKET 

else  if  Pit  2  of  CONTROL-FIELD  =  0  then  VAL J D-PRIMARY - 
PACKET  is  an  S-FRAME-COMMAND 
else  VALID-PRIMARY-PACKET  is  a  U- FRAME -COMMAND 
Else  VAL IP -PR I  MARY -PACKET  is  an  INVALID-PRIMARY-PACKET-TYPE 


PROCESS  NAME:  VALIDATE  I -FRAME  PACKET 

PROCESS  NUMBER:  3.3.1 

PROCESS  DESCRIPTION: 

If  N ( S)  of  the  PRIMARY- I -FRAME-PACKET  =  SECONDARY -V ( R) 
then  the  PFIMARY-I-FRAMF-FACKET  is  a  VALID-PR1 MARY- 
I -FRAME- PACKET 

Else  it  is  an  OUT- OF -SEQUENCE -PR I  MARY- 1 -FRAME 
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PROCESS  NAME:  PARSE  I-FRAME 

PROCESS  NUMBER:  3.3.2 

PROCESS  DESCRIPTION: 

Output  the  first  octet  of  the  VAL I D-PRIMARY -I -FRAME  as  the 
PRIMARY- I-FRAME-CONTROL-FIELD 
Output  Bit  5  of  the  first  octet  of  the  VAL 1 D - PR I  MARY - 1 - 
FRAME  as  the  I-FRAME-POLL-BIT 
Output  all  octets  following  the  first  octet  as  the 
TRAN SMITTED-PRIMARY-NODE-LEVEL-3 -PACKET 


PROCESS  NAME:  PARSE  I-FRAME  CONTROL  FIELD 

PROCESS  NUMBER:  3.3.3 

PROCESS  DESCRIPTION: 

Output  Bits  2,3,4  as  N(S) 

Output  Bits  6,7,8  as  N(R) 


PROCESS  NAME:  PARSE  S-FRAME  COMMAND 

PROCESS  NUMBER:  3.4.1 

PROCESS  DESCRIPTION: 

S- FRAME-CONTROL-FIELD  =  First  octet  of  S-FRAME-COMMAND 
S-FRAME-POLL-EIT  =  Bit  5  of  S-FRAME-CONTROL-FI ELD 


PROCESS  NAME:  PARSE  S-FRAME  CONTROL  FIELD 

PROCESS  NUMBER:  3.4.2 

PROCESS  DESCRIPTION: 

Case  Bits  3,4  of 

00:  RR-COMMAND 

10:  RNR-COMMAND 

01:  REJ -COMMAND 

11:  INVALID-S-FRAME-COMMAND 


PROCESS  NAME:  SEND  READY  STATUS  AND  EXTRACT  N ( R ) 

PROCESS  NUMBER:  3.4.3 

PROCESS  DESCRIPTION: 

Output  READY-INDICATION 

Set  PR I MARY -READY -N (R)  =  Bits  6,7,8  of  RR-COMMAND 


PROCESS  NAME:  SEND  BUSY  STATUS  AND  EXTRACT  N(R) 

PROCESS  NUMBER:  3.4.4 

PROCESS  DESCRIPTION: 

Output  PRIMARY-BUSY-INDICATION 

Set  BUSY-PRIMARY-N ( R)  =  Bits  6,7,8  of  RNR-COMMAND 
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PROCESS  NAME:  SEND  REJECT  CONDITION  AND  EXTRACT  K ( R ) 

PROCESS  NUMBER:  3.4.5 

PROCESS  DESCRIPTION: 

Output  PRIMARY-REJECTION-CONDITION 

Set  REJECT-PRIMARY-N (R)  =  Bits  6,7,8  of  REJ-COMMAND 


PROCESS  NAME:  PARSE  U-FRAME  COMMAND  CONTROL  FIELD 

PROCESS  NUMBER:  3.5.1 

PROCESS  DESCRIPTION: 

COMMAND-MODI  PIER-BITS  =  Bits  3, 4, 6, 7, 8  of  the  U-FRAME- 

COMMAND 

U-FRAME-POLL-BIT  =  Bit  5  of  the  U-FRAME-COMMAND 


PROCESS  NAME:  DECODE  COMMAND  MODIFIER  BITS 

PROCESS  NUMBER:  3.5.2 

PROCESS  DESCRIPTION: 

Case  Bits  3, 4, 6, 7, 8  of 

(11100) :  Output  TRANSMITTED-SABM-COMMAND 

(00010):  Output  DISC-COMMAND 

Otherwise:  Output  IN VALID -U-FRAME-COMMAND 


PROCESS  NAME:  DISCONNECT  LINK 

PROCESS  NUMBER:  3.5.3 

PROCESS  DESCRIPTION: 

Upon  receipt  of  a  DISC-COMMAND 

If  not  in  Disconnected  state  then 
Set  SECONDARY  NODE  state  to  Disconnected  state 
Output  DISC-UA-RESPONSE 
Else  output  DM-RESPONSE 


PROCESS  NAME:  SET  UP  LINK 

PROCESS  NUMBER:  3.5.4 

PROCESS  DESCRIPTION: 

Upon  receipt  of  a  TRANSMITTED-SABM-COMMAND 

Reset  SECONDARY-V ( R)  and  SECONDARY-V ( S)  to  0 
Set  SECONDARY  NODE  state  to  Ready 
Output  SABM-UA-RESPONSE 
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PROCESS  NAME:  RESET  V(S) 

PROCESS  NUMBER:  3.6.1 

PROCESS  DESCRIPTION: 

When  a  PRIMARY-REJECTION-CONDITION  is  received 

Update  SECONDARY-V ( S)  to  equal  the  PRI MARY-REJ FCT-N ( R) 
Output  a  REJ-READY-INDI CATION 

When  a  SABM-UA-RESPONSE  is  received  reset  SECONDARY-V ( S)  to  C 


PROCESS  NAME:  UPDATE  LOWER  WINDOW  EDGE 

PROCESS  NUMBER:  3.6.2 

PROCESS  DESCRIPTION: 

Set  UPDATED-LOWER-WINDOW-EDGE  =  N(P.) 


PROCESS  NAME: 

PROCESS  NUMBER: 
PROCESS  DESCRIPTION: 
If  POLL-BIT  =  1  then 


PROCESS  NAME: 

PROCESS  NUMBER: 
PROCESS  DESCRIPTION: 
While  SECONDARY  NODE 
SECONDARY-V ( S) 


SET  RESPONSE 
3.6.3 


FINAL  BIT 


set  SECONDARY -PINAL- BIT  =  1 


PLACE 

3.6.4 


I-FRAME  IN  X . 2  5  LINK 


and 

and 


V:  IN  DOW  ED- 1  -  FRAME 


If 


is  in  Ready  state 
<  UPDATED-LOWER-WINDOW-EDGE  - 
no  REJ-READY-INDI CATION  is  present 
Send  SECONDARY -LEVEL -3 -PACKET  as 
with  N(R)  =  SECONDARY-V (R) 

N ( S)  =  SECONDARY -V(S) 

Increment  SECONDARY-V( S) 

PEJ- READY- INDICATION  then 

Retransmit  SECONDARY-LEVEL-3 -PACKETS  starting  with  the 
WINDOW ED- I-FRAME  with  N<S)  =  SECONDARY -V ( S) 
Increment  SECONDAP.Y-V(  S) 


PROCESS  NAME: 

PROCESS  NUMBER: 

PROCESS  DESCRIPTION: 
Select  packets  from,  the 
following  priority 


SELECT 

3.6.5 


PACKET  FOR  X.25  LINK 


transmit  queue  according  to  the 


I  f 


Priority  1 
Priority  2 
Priority  3 
Priority  4 
the  queue  is 


CMDR(FRMR) -RESPONSE 
DISC-UA-REPONSE  or  DM-RESPONSE 
PP-RESPONSE  or  FNR-RESPONSE 
WIN DOW ED- I -FRAME 
empty  for  MAX-TIME-BETWEEN-UPDATFS 


then 


'  o  n  a 


an  RR-RESPONSE  with  N(P)  =  SECONDARY-N ( R)  to  update 
PRIMARY  NODE  LOWER-WIN DOW -EDGE 
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Generate  FCS-BLOCK 

Divide  the  VALID-LENGTH-PACKET  by  the  CRC  polynomial  which 
is  x**16  +  x**12  +  x**5  +  1  modulo  2 
Multiply  the  VALID-LENGTH-PACKET  by  x**16  and  then  divide 
it  by  the  CRC  polynomial 

Add  the  remainders  of  the  above  two  operations  on  the 

VALID-LENGTH-PACKET  modulo  2  and  take  the  1's  complement 
The  result  is  the  FCS-ELOCK 
Append  the  FCS-BLOCK  to  the  packet  to  be  transmitted 
Set  FINAL-BIT  if  SECONDARY-FINAL-BIT  is  set 
Output  a  SECONDARY -LEVEL- 2- PACKET 


PROCESS  NAME:  RESPOND  TO  STATUS  REQUEST 

PROCESS  NUMBER:  3.6.6 

PROCESS  DESCRIPTION: 

If  POLL-BIT  is  set  then 

if  SECONDARY  NODE  is  in  Ready  state  then  output  RR-RESPONSE 
else  output  RNR-RESPONSE 


PROCESS  NAME:  REQUEST  RECOVERY  FROM  PROCEDURE  ERROR 

PROCESS  NUMBER:  3.7 

PROCESS  DESCRIPTION: 

If  an  INVALID-LENGTH-PRIMARY-PACKET  or  an  INVALID-PRIMARY  - 
PACKET-TYPE  or  an  OUT-OF-SEQUENCE-PRIMARY-I-FRAMF-PACKET 
is  received  then  output  a  CMDR (FRMR ) -RESPONSE 


PROCESS  NAME:  SEND  PACKET 

PROCESS  NUMBER:  3.R 

PROCESS  DESCRIPTION:  SEE  PROCESS  l.P 
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Appendix  D 

Module  Structure  Charts 

This  appendix  contains  the  complete  set  of 
structure  charts  needed  to  specify  the  design 
software  for  TELNET.  These  charts  were  drawn  using 
and  Constantine's  structured  design  techniques  (Ref. 
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ABPsndik  £ 

Source  Code  for  the  Network  Command  Language  Interpreter 

This  appendix  contains  the  PASCAL  source  code  for  the 
network  command  language  interpreter.  In  its  present 
configuration,  the  program  is  structured  to  allow  testing  of 
the  high-level  protocol  modules. 
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Appendix  £ 

Testing  Documention 

for  the  Network  Command  Language  Interpreter 

This  appendix  contains  the  final  set  of  test  cases  that 
was  used  to  test  the  network  command  language  interpreter. 
Documentation  on  the  rationale  for  each  test  input  is 
included  with  the  test  case. 
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TYPE  IN  TEST  DESCRIPTION 
HFt.P  FEOnrST  POP  FILE  TRANSFER 
f.fu  IN  TEST  CAGE  #5 

help  .file  TP.'.Nsrrn! 

FIlE  TRANSFER  COMMAND  F HRMAT  IS  AS  FOLLOUS! 

NCTUCFK.  TRANSFER  FILE»FN=FILENAME  rDD=DESTDEV.  DH«flESTHOST  »SO» SOURCE DEV  *  SH»SOURCEHOST 

T *  MEANS  THAT  TRANSFER  FILE  MAY  BE  ABBREVIATED 

PARAMETERS  MAY  BE  ENTERED  IN  ANY  ORDER 

ALL  PARAMETERS  ARE  LIMITED  TO  20  CHAR 

SGURCEDEV  CANNOT  BE  THE  CONSOLE  OR  PRINTER 


TYPE  IN  TCST  DESCRIPTION 

HELP  P COLT  ST  TOP  SESSION  CONTROL  COMMANDS 
T Y T  E  IN  TEST  CAPE  #6 
HFLP .SESSION  COMMANDS! 

THE  SESSION  CONTROL  COMMANDS  ARE  AS  FOLLOWS! 

NETWORK  #  LOGON »  LOCAL HOSTNAME 
NETWORK. LOGOUT 

THE  LQC ALHG5TNAME  IS  THE  NAME  OF  THE  HOST  TO  UHICH  ALL  LOCAL  COMMANDS  WILL 
BE  ROUTED  AMI  NEED  NOT  BE  THE  NAME  OF  THE  HOST  TO  WHICH  THE  USER  IS 
PHYSICALLY  CONNECTED.  IF  NO  LOC ALHOSTNAME  IS  SPECIFIED  THEN  THE  HOST  TO 
UHICH  THE  USER  IS  PHYSICALLY  CONNECTED  IS  ASSUMED 


TY*E  IN  TEST  DESCRIPTION 

HELF  FNF'PECUESr  FOP  NETWORK  CONFIGURATION 
TYPE  IN  TEST  CASE  8 
HCwF.  LIST  CPNrK'f  AT  TON  ■ 

THE  HCST5  AND  OCVICCS  THAT  APE  ACTIVE  ON  THE  NETWORK  ARE  AS  FOLLOWS! 
NETUCF.K  CONFIGURATION  TABLE  PRINTED  OUT 


TYPE  IN  TEST  DESCRIPTION 
ah-fevi *rrn  or n  help  fedwcst 
T ( •  E  IN  TEST  case  #0 
H  ’ 

THE  GCNEPAL  COMMAND  FORMATS  ARE  AS  FOLLOWS! 

NETUCM.f TRANSFER  FILE.FILE  TRANSFER  PARAMETERS 
NETWORK .LOGON. LOC ALHOSTNAME 
NETWORK. LOGOUT 
NETWORK .HELP. HELPP ARAM 

THE  HELP  REQUEST  PARAMETERS  ARE  AS  FOLLOUS! 
f  )llE  T P A N 7 F E R 
L'-IST  CONFIGURATION 

SESSION  commands 

THE  RAFT  NTHESES  IN  THE  ABOVE  FORMATS  INDICATE  THAT  ONLY  THE  FIRST  LETTER 
IS  REQUIRED 


TYPE  IN  TEST  DESCRIPTION 

AFT  FT 7ANAMATCD  FILE  TRANSFER  HE. \. NLP  REQUEST 

TYTE  IN  TEST  CASE  19 

H,Fi 

FILE  TRANSFER  COMMAND  FORMAT  IS  AS  FOLLOWS! 

NETWORK. TRANSFER  FILE. FN*F ILENAME  rDDeDESTDEV»  DH* DEBT HOST  » SD* SOURCE DEV »  SH*SOURCEHOST 


ALII'  COMMAND —  COMMAND  riELD?>  loaon 

AL  I  r.  rOMMANr--CC,".NANP  FIELP?>  loaon 

ALII.  COMMAND  — COMMAND  FIELD7:-  lloaon 
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THE  HELP  REQUEST  PARAMETERS  ARE  AS  FOLLOWS! 

F)ILE  TRANSFER 
DIET  CONFIGURATION 
S)ESSION  COMMANDS 

THE  PARENTHESES  IN  THE  ABOVE  FORMATS  INDICATE  THAT  ONLY  THE  FIRST  LETTER 
IS  REQUIRED 


1 


T)  MEANS  THAT  TRANSFER  FILE  HAY  PE  ABBREVIATED 
PARAMETERS  MAY  PE  ENTERED  IN  ANY  ORDER 
ALL  PARAMETERS  ARE  LIMITED  TO  20  CHAR 
SGURCEDEV  CANNOT  BE  THE  CONSOLE  OR  PRINTER 


TYPE  IN  TEST  DESCRIPTION 

AFDRF'.'IATED  SESSION  COMMANDS  HELP  REOUUEST 
TYPE  IN  TEST  CASE  #10 
H»r ' 

THE  SESSION  CONTROL  COMMANDS  ARE  AS  FOLLOUS: 
NETWORK  »  LOGON »LOC ALMOST NAME 
NETWORK  t  LOGOUT 


THE  LCCALHOSTNAME  IS  THE  NAME  OT  THE  HOST  TO  WHICH  ALL  LOCAL  COMMANDS  WILL 
PE  ROUTED  AND  NEED  NOT  BE  THE  NAME  OF  THE  HOST  TO  WHICH  THE  USER  IS 
PHYSICALLY  CONNECTED.  IF  NO  LOCALHOSTNAME  IS  SPECIFIED  THEN  THE  HOST  TO 
WHICH  THE  USER  IS  PHYSICALLY  CONNECTED  IS  ASSUMED 


TYPE  IN  TEST  DESCRIPTION 
ABBREVIATED  CONFIGURATION  REQUEST 
TYPE  IN  TEST  CASE  111 
M  •  L  ! 

THE  HOSTS  AND  DEVICES  THAT  ARE  ACTIVE  ON  THE  NETWORK  ARE  AS  FOLLOUS? 
NETWORK  CONFIGURATION  TABLE  PRINTED  OUT 


TYFE  IN  TEST  DESCRIPTION 
NULL  PARAMETER  IN  HELP  REQUEST 
T Yr  E  IN  TEST  CASE  *12 
Hr  ' 

THE  GENERAL  COMMAND  FORMATS  ARE  AS  FOLLOWS? 

NETWORK » TRANSFER  FILE  .FILE  TRANSFER  PARAMETERS 
NCTWQfU  .LOGON. LOCALHOSTNAME 
NETWORK. LOGOUT 
NETWORK » HELP » HELPPARAM 

THE  HELP  REQUEST  PARAMETERS  ARE  AS  FOLLOWS? 

F  >  I LE  TRANSFER 
L ) I S T  CONFIGURATION 

s>ee:ion  commands 

THE  PARENTHESES  IN  THE  ABOVE  FORMATS  INDICATE  THAT  ONLY  THE  FIRST  LETTER 
IS  REQUIRED 


TYPE  IN  TEST  DESCRIPTION 

IN'. ‘LID  PARAMETER  IN  HELP  REQUEST 

TYPE  IN  TEST  CASE  #13 

PrLr .  NETWORK ! 

INVALID  HELP  REQUEST  PARAMETER--PARAM?': 

THE  GENERAL  COMMAND  FORMATS  ARE  AS  FOLLOUS? 

NETWORK. TRANSFER  FILE. FILE  TRANSFER  PARAMETERS 

NET WORK. LOGON. LOCALHOSTNAME 

NETUORK. LOGOUT 

NET WORK. HELP. HELFPARAM 

THE  HELP  REQUEST  PARAMFTERS  ARE  AS  FOLLOWS? 

F ) ILE  TRANSFER 
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L>I$T  CONFIGURATION 
S  > ESS I ON  COMMANDS 

the  farentheses  in  the  above  formats  indicate  that  only  the  FIRST  LETTER 

13  REQUIRED 


TYPE  IN  TEST  DESCRIPTION 

MULTIPLE  PARAMETERS  IN  HELP  REQUEST! 

TYPE  IN  TEST  CASE  #14 
HELP » L  » 5 » P ! 

THE  HOSTS  AND  DEVICES  THAT  ARE  ACTIVE  ON  THE  NETWORK  ARE  AS  FOLLOWS*. 
NETWORK  CONFIGURATION  TABLE  PRINTED  OUT 


TYPE  IN  TEST  DESCRIPTION 

SESSION  CONTROL  TEST  OF  INVALID  LOCAL  HOST 
TYPE  IN  TEST  CASE  *1$ 

LOGON. ZILOG ' 

HOST  NOT  ACTIVE  ON  NETWORK-HOST  N AME?> 

USER  LOGGED  ON  NETWORK  UITH  USER  HOST  AS  LOCAL  HOST 


TYPE  IN  TEST  DESCRIPTION 

SESSION  CONTROL  COMMAND  WITH  INVALID  COMMAND 

TYPE  IN  TEST  CASE  #16 

LOGOFF 

i 

INVALID  SESSION  CONTROL  COMMAND  — CMD?>  LOGOUYT 
COMMAND  ROUTING  TABLE  SET  BACK  TO  USER  HOST 
SUMMARY  OF  FILE  TRANSFERS 
USER  LOGGED  OUT 


TYPE  IN  TEST  DESCRIPTION 

SESSION  CONTROL  COMMAND  WITH  NO  LOCAL  HOST  SPECIFIED 
TYPE  IN  TEST  CASE  #17 
LOGON  • 

USER  LOGGED  ON  NETWORK  WITH  USER  HOST  AS  LOCAL  HOST 


TYPE  IN  TEST  DESCRIPTION 

SESSION  CONTROL  COMMAND  SHOWING  LOGIN  ALLOWED 
f YF  E  IN  TEST  CASE  #10 

LOGIN f v; V » 

CGMMAND  ROUTING  TABLE  UPDATED  TO  SHOW  LOCAL  HOST  AS  VAX 
USER  LOGGED  ON  NETUORK  WITH  VAX  AS  THE  LOCAL  HOST 


TYPE  IN  TEST  DESCRIPTION 
LOGOUT  COMMAND  UITH  PARAMETERS 
TYTE  IN  TEST  CASC  #19 
LOGOUT. VAX! 

COMMAND  ROUTING  table  set  back  TO  USER  HOST 
SUMMARY  OF  PILE  TRANSFERS 
USER  LOGGED  OUT 
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TYFE  IN  TEST  DESCRIPTION 

I  Of. ON  CGHxftND  WITH  MULTIPLE  LOCAL  HOSTS  SPECIFIED 

Tvr-c  in  YrsT  cas c  i?o 

V-*.rC  '•VAX  r  INTEl  f?{jVh« 

COMMAND  ROUTING  TABLE  UPDATED  TO  SHOW  LOCAL  HOST  AS  VAX 
IJCEP  LOGGED  ON  NETUORK  UITH  VAX  AS  THE  LOCAL  HOST 


«  R'JN  EXTRNET 

EXECUTING  TEST  PROCRAM--TYPE  IN  »  TEST  CASES 
10 

TYPE  IN  TEST  DESCRIPTION 
LOGON  COMMAND  FOR  NOVA 
TYPE  IN  TEST  CASE  #1 

LOGON f NOVA » 

COMMAND  ROUTING  TABLE  UPDATED  TO  SHOW  LOCAL  HOST  AS  NOVA 
USER  LOGGED  ON  NETWORK  UITH  NOVA  AS  THE  LOCAL  HOST 


TYFE  IN  TEST  DESCRIPTION 

LOGON  COMMAND  WITH  MULTIPLE  NULL  PARAMETERS  AND  ONE  VALID  ONE 
TYPE  IN  TEST  CASE  »2 

LOOC'Nf  *  F  F  F  F  »  F  F  F  F  »  F  F  VAX  ! 

USER  LOGGED  ON  NETUORK  UITH  USER  HOST  AS  LOCAL  HOST 


TYFE  IN  TEST  DESCRIPTION 
LOGON  USING  ABBREVIATIONS 
TYPE  IN  TEST  CASE  13 
L.H! 

INVALID  SESSION  CONTROL  COMMAND-~CMD?>  LOGON 

COMMAND  ROUTING  TABLE  UPDATED  TO  SHOU  LOCAL  HOST  AS  NOVA 

USER  LOGGED  ON  NETUORK  UITH  N  AS  THE  LOCAL  HOST 


TYPE  IN  TEST  DESCRIPTION 
LOGON  TO  INTEL  USING  ABBREVIATION 
TiTE  IN  TEST  CASE  *4 
LCGONf I 

COMMAND  ROUTING  TABLE  UPDATED  TO  SHOW  LOCAL  HOST  AS  INTEL 
USER  LOGGED  ON  NETUORK  UITH  I  AS  THE  LOCAL  HOST 


TYPE  IN  TEST  DESCRIPTION 

HELP  R f G l : r S T  WITH  PARAMETER  THAT  IS  TOO  LONG 

TYPE  IN  TEST  CASE  »5 

HELF  .FFFFFFFFFFFFFFFFFFrrFFFFrF? 

INVALID  HELP  REQUEST  PARAMETER- -PARAM*^  FFFFFFFFFFFFFFFFFFFFF 
FILE  TRANSFER  COMMAND  FORMAT  IS  AS  FOLLOWS: 

NETWORK f TRANSFER  F ILE  f  FN- FILENAME  fDD  =  DESTDEVfDH*DESTHOSTf  SD*SOURCEDEV f  SH*SOURCEHOST 

T>  MEANS  THAT  TRANSFER  FILE  MAY  BE  ABBREVIATED 

PARAMETERS  MAY  BE  ENTERED  IN  ANY  ORDER 

ALL  PARAMETERS  ARE  LIMITED  TO  20  CHAR 

30URCEDEV  CANNOT  BE  THE  CONSOLE  OR  PRINTER 
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TvfE  IN  TEST  DESCRIPTION 

1 ! '  1  r.C"LT“T  CW'UTX’JITH  PARAMETER  THAT  IS  EXACTLY  20  CHAR 
'  E  I  'J  ’EOT  CASE  IS 
‘  ■  i '  .r~Frrr'*r-TrrrrrFFFrr  ! 

FILE  Tr.ANSrCR  COMMAND  FORMAT  IS  AS  FOLLOWS: 

NETWORK r TRANSFER  F ILE » FN=FILENAME * OD-OESTOEV » DH=DESTHOST t $D*SOURCEDEV » SH-SOURCEHOST 

T '  MEAN'S  THAT  TRANSFER  FILE  MAY  BE  ABBREVIATED 

PARAMETERS  MAY  BE  ENTERED  IN  ANY  ORDER 

ALL  PARAMETERS  ARE  LIMITED  TO  20  CHAR 

SCURCEDEV  CANNOT  BE  THE  CONSOLE  OR  PRINTER 


TYPE  IN  TEST  DESCRIPTION 

HELP  REQUEST  WFI TH  A  PARAMETER  THAT  IS  21  CHARACTERS  LONG 
TYPE  IN  TEST  CASE  17 
H.LLLLLLLLU-LLLt  LLLLLLL  » 

INVALID  HELP  REQUEST  PARAMETER- -FAR AM?N  LLLLLLLLL 

THE  HOSTS  AND  DEVICES  THAT  ARE  ACTIVE  ON  THE  NETWORK  ARE  AS  FOLLOWS.* 
NETWORK  CONFIGURATION  TABLE  PRINTED  OUT 


TYPE  IN  TEST  DESCRIPTION 

SCOTCH  CONTROL  COMMAND  UITH  A  20  CHAR  PARAMETER 
T v r  c  IN  TEST  CASE  *0 
t  nr-n  n ,  vvvvvvvvvvvvvwvvvvv » 

COMMAND  POUTING  TABLE  UPDATED  TO  SHOW  LOCAL  HOST  AS  VAX 

UCEf  LOGGED  ON  NETWORK  UITH  VVVVVVVVVVVVVVVVV VW  AS  THE  LOCAL  HOST 


T  Y?  C  IN  TEST  DESCRIPTION 

Ci.TG TCN  CONTROL  COMMAND  WITH  A  21  CHAR  PARAMETER 
T , r  r  IN  TEST  CASE  *9 
LrroN.iiTTinimnniiiiiii 

MS? T  NOT  ACTIVE  ON  NETWORK --HOST  NAHE*>  IIIIIIIII 
CCmmaMD  routing  TABLE  UPDATED  TO  SHOW  LOCAL  HOST  AS  INTEL 

u:ep  logged  on  network  with  iirnini  as  the  local  host 


T>FE  IN  TEST  DESCRIPTION 

NULL  COMMAND 

TYPE  IN  TEST  CASE  110 

i 

command --command  fields  logout 

COMMAND  POUTING  TABLE  SET  BACK  TO  USER  HOST 
SUMMARY  OF  FILE  TRANSFERS 
USER  LOGGED  OUT 
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Appendix  Q 

DELNET  User's  Manual 

This  appendix  contains  a  user's  manual  for  the  network 
command  language  interpreter  in  its  present  version  as 
documented  by  Appendix  E.  The  manual  consists  basically  of  a 
description  of  the  step-by-step  procedure  for  using  this 
program. 

Since  the  lower-level  protocols  have  not  been 
implemented,  it  is  necessary  to  log  in  to  the  VAX-11/780  to 
access  the  network  command  language  interpreter.  This  log 
in  procedure  entails  the  following: 

Username:  HOBART  <CR> 

Password:  XXX  <CR> 

WELCOME  TO  VAX  VERSION  1.4 
$ 


At  this  point,  the  network  command  language  interpreter 
can  be  activated  by  typing  NETWORK  <CR>  after  the 
dollar  sign  prompt.  The  network  command  language 
interpreter  will  respond  with 

EXECUTING  TEST  PROGRAM — TYPE  IN  #  TEST  CASES 

After  an  integer  has  been  entered  by  the  user,  the 
network  command  language  interpreter  will  respond 

TYPE  IN  TEST  DESCRIPTION 
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This  allows  the  user  to  document  what  testing  is  being 
accomplished  by  this  test  input.  A  carriage  return  (<CR>) 
signals  the  end  of  the  user  input.  The  network  command 
language  interpreter  will  then  respond 

TYPE  IN  TEST  CASE  #1 

Any  of  the  commands  described  in  the  following  sections 
may  then  be  entered.  The  command  must  be  terminated  with  an 
exclamation  mark  and  a  carriage  return.  The  exclamation 
mark  is  used  as  a  special  character  to  represent  the  end  of 
the  network  command. 

File  Transfers 

A  file  transfer  command  consists  of  the  following 
string : 

TRAN SFER  FI LE , FN  =F I LEN AME , SD=SOURCE_DEVICE_NAME , 
SH=SOURCE_HOST_NAME , DD=DESTINATION_DEVICE_NAME , 
DH=DESTINATION_HOST„NAME ! 

The  parameters  may  be  entered  in  any  order  but  may  not 
be  longer  than  20  characters  each.  The  maximum  parameter 
length  may  be  changed  by  changing  the  value  of  MAXPARLNG  in 
the  source  code  and  recompiling  and  relinking  the  program. 
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Session  Control 


The  network  command  language  interpreter  will  accept 
the  following  session  control  commands: 

LOGIN, HOST_NAME 1 
LOGOUT! 

User  Help  Information 

The  user  can  request  information  by  typing  any  of  the 
following  commands: 

HELP! 

HELP, FILE  TRANSFER! 

HELP, SESSION  COMMANDS! 

HELP, LIST  CONFIGURATION! 

The  output  from  these  help  requests  is  shown  on  the 
following  pages.  Finally,  Table  10  in  the  main  body  is 
included  here  also  to  show  the  valid  keywords.  The 
underlined  letters  are  the  allowable  abbreviations. 
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Table  10 


Valid  Keywords 

Network  Command  Parameter 

LOGIC 

LOGOUT 

TRANSFER  FILE 
HELP 


File  Transfer  Parameters 

Source  Host  (Cfis) ,  Destination  Host  (LUs) , 

INTEL 

MOVA 

i£AX 

Source  Device  f SD=0 

£LOPPYDISK 

HARDDISK 

TAPE 

Destination  Device  (EDs) 

CONSOLE 
£LOPPYDISK 
HARDDISK 
PRINTER 
I A  PE 


Local  flQS-t  Parameter 

Null  (Defaults  to  user  host) 

INTEL 

UOVA 

UAX 


Help  parameter 

£ILE  TRANSFER 
LIST  CONFIGURATION 
CESSION  COMMANDS 
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Equipment  Corporation  VAX-11/780,  and  a  Data  General  Nova. 
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conjunction  with  a  basic  routing  algorithm  using  a  lockup 
table  stored  in  each  UNID.  The  network  command  language 
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commands,  and  user  help  requests  to  be  parsed  and  the 
appropriate  parameters  passed  to  lower-level  modules. 
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